• [00:00:33] * BeagleBot (~PircBot@ec2-50-17-196-130.compute-1.amazonaws.com) has joined #beagle
  • [00:00:33] * Topic is 'http://beagleboard.org/chat has a guide on how to ask questions and links to the logs | never ask to ask, just ask | be patient | pastebin a boot log | http://ahsoftware.de/Beaglebone_Black_Boot_explained.svg | http://beagleboard.org/latest-images | http://beagleboard.org/Support/bone101 | direct bonescript/node.js questions to #beagle-bonescript | books: http://bit.ly/bbb-books'
  • [00:00:33] * Set by KotH!~attila@erica.kinali.ch on Wed Jul 15 13:55:07 UTC 2015
  • [00:00:33] * BeagleBot (~PircBot@ec2-50-17-196-130.compute-1.amazonaws.com) has joined #beagleboard
  • [00:00:33] * BeagleBot (~PircBot@ec2-50-17-196-130.compute-1.amazonaws.com) has joined #beaglebone
  • [00:01:11] * ds2 looks at docs
  • [00:01:22] <zmatt> mDDR/DDR2/DDR3
  • [00:02:06] <zmatt> /DDR3L
  • [00:02:29] <ds2> there was something not supported on am335 that was on the dm37x
  • [00:03:12] * kilroi``` (~kilroy@ip-94-114-228-28.unity-media.net) has joined #beagle
  • [00:04:52] <zmatt> plenty of things, but w.r.t. memory that would be mSDR
  • [00:05:00] <zmatt> that and 32-bit wide memory
  • [00:06:37] <ds2> ah 32 vs 16 must have been it
  • [00:06:53] * kilroi` (~kilroy@ip-94-114-228-28.unity-media.net) Quit (Ping timeout: 276 seconds)
  • [00:07:19] * IrishGringo (~chatzilla@2601:586:c200:6eaa:ccf9:6106:1c92:8d84) has joined #beagle
  • [00:09:30] * bkearns (~bkearns@216-75-239-130.static.wiline.com) Quit (Read error: Connection reset by peer)
  • [00:10:07] * bkearns (~bkearns@216-75-239-130.static.wiline.com) has joined #beagle
  • [00:11:26] * Starduster (~guest@unaffiliated/starduster) Quit (Ping timeout: 276 seconds)
  • [00:12:26] <zmatt> yeah the 16-bit is a bit meh, then again it supports mDDR-400 / DDR2-533 / DDR3-800 versus the mDDR-266 of the dm37xx
  • [00:12:55] * Starduster (~guest@unaffiliated/starduster) has joined #beagle
  • [00:15:10] * darkfader (~darkfader@ip3e8346be.speed.planet.nl) Quit (Ping timeout: 240 seconds)
  • [00:15:38] * Spidler (~spider@vpn.takeit.se) Quit (Ping timeout: 260 seconds)
  • [00:15:45] * Spidler (~spider@vpn.takeit.se) has joined #beagle
  • [00:18:19] * florian (~fuchs@Maemo/community/contributor/florian) Quit (Ping timeout: 252 seconds)
  • [00:19:49] * darkfader (~darkfader@2001:610:600:896d:9a3:eb21:6a8c:db4e) has joined #beagle
  • [00:20:25] * RobotGuy (~hybotics@ip72-220-121-210.sd.sd.cox.net) has joined #beagle
  • [00:23:22] <ds2> wonder if a 2 layer am335x design is doable at all
  • [00:25:41] * Set_ (~Set_@ip70-189-47-143.lf.br.cox.net) has joined #beagle
  • [00:26:22] * tai271828 (~tai271828@111.248.104.52) has joined #beagle
  • [00:26:42] * darkfader (~darkfader@2001:610:600:896d:9a3:eb21:6a8c:db4e) Quit (Quit: Read error: Connection reset by peer)
  • [00:32:57] * James_Johnson (~clayshoot@ip70-189-76-25.ok.ok.cox.net) has joined #beagle
  • [00:33:05] * nighty-_ (~nighty@p12125-ipngn2601marunouchi.tokyo.ocn.ne.jp) has joined #beagleboard
  • [00:33:07] * James_Johnson (~clayshoot@ip70-189-76-25.ok.ok.cox.net) Quit (Client Quit)
  • [00:34:05] * IrishGringo (~chatzilla@2601:586:c200:6eaa:ccf9:6106:1c92:8d84) Quit (Read error: Connection timed out)
  • [00:35:44] <zmatt> 2 signal layers you mean?
  • [00:36:50] <ds2> no, 2L
  • [00:37:01] <zmatt> well, not without violating every layout rule in the datasheet
  • [00:37:08] <ds2> sigh
  • [00:37:25] <ds2> 4L flex is a pain... a Beagle like board on flex would be useful
  • [00:37:50] <ds2> a lot of those rules will have to be worked out again for flex... think a lot of them assume FR4
  • [00:38:13] <zmatt> depend also on how many interfaces you're willing to sacrifice to make room I guess
  • [00:38:44] <ds2> let's say something that can start up u-boot (min. serial out + ram)
  • [00:39:19] <zmatt> so you'd have a signal layer on top and a power/ground plane on bottom...
  • [00:39:37] <ds2> or sacrafice a dedicated power/gnd layer
  • [00:39:45] <zmatt> that sounds like a very bad idea
  • [00:40:04] <ds2> even for the lowest OPP?
  • [00:41:16] <zmatt> well tbh, if you're going to throw everything out the window you basically would need to do full simulation anyway, or be really good at guesswork and pray
  • [00:42:06] <ds2> that would raise the question of how accurate are the models
  • [00:42:37] <zmatt> set all slews to "slow" instead of the datasheet-recommended "fast" since you wouldn't have a ground plane for return currents of sharp transients
  • [00:43:44] <ds2> that's all fine once I get control... does the ROM cooperate?
  • [00:44:00] * clonak_ (~clonak@118-92-142-3.dsl.dyn.ihug.co.nz) has joined #beagle
  • [00:44:15] <zmatt> you could use a small NOR flash and "fast xip boot"
  • [00:44:24] <zmatt> that gets you control very very early
  • [00:44:34] <ds2> ROM doesn't run in XIP mode?
  • [00:44:36] * clonak (~clonak@203.96.195.155) Quit (Ping timeout: 272 seconds)
  • [00:45:09] <ds2> or are you implying that ROM is less likely to do something bad if XIP is selected
  • [00:45:29] * vagrantc (~vagrant@unaffiliated/vagrantc) Quit (Quit: leaving)
  • [00:45:38] <zmatt> high-speed transfers
  • [00:45:43] <zmatt> over external interfaces
  • [00:46:12] <ds2> i was thinking UART boot is safer
  • [00:46:52] <zmatt> you're really not in a hurry to boot the system then are you? ;) but actually, "fast xip" mode transfers control before PLLs are setup iirc
  • [00:47:12] <zmatt> while uart boot will already have the PLLs setup at opp100
  • [00:47:14] <ds2> nope
  • [00:47:19] <ds2> proof of concept
  • [00:48:12] <ds2> the other half of it is flex doesn't really do that well with fine traces
  • [00:48:23] <ds2> so breaking out a parallel bus for NOR can get troublesome
  • [00:49:34] <zmatt> I just realized that the thinness of flex probably also means a ground plane is troublesome anyway.... what kind of single-ended impedance are we looking at?
  • [00:49:55] <ds2> <ds2> a lot of those rules will have to be worked out again for flex... think
  • [00:49:55] <ds2> +a lot of them assume FR4
  • [00:50:01] <ds2> :D
  • [00:50:24] <ds2> i suspect it can vary quite a bit depending on thickness of the kapton
  • [00:51:37] <zmatt> yes, you'd need to know the thickness of kapton, width and thickness of the trace, and relevant constants of kapton instead of fr4
  • [00:52:14] <zmatt> fill those in in one of the many online calculators for microstrip impedance
  • [00:52:19] <ds2> *nod* was more of referring to a wider variation of available thicknesses then FR4
  • [00:52:30] <ds2> not just to the physical requirements that drive impedences
  • [01:02:44] <zmatt> ds2: http://pastebin.com/nm6jUMAV this illustrates what's special about fast external xip boot
  • [01:04:01] <ds2> ah
  • [01:04:18] <ds2> know off hand if it will work with an 8bit ROM?
  • [01:04:54] <zmatt> I think so, lemme check the disassembly (no I don't trust the TRM :P )
  • [01:06:10] * nofxx (~nofxx@unaffiliated/nofxx) Quit (Ping timeout: 240 seconds)
  • [01:13:46] * Gareth (~garethFre@znc.wiked.org) Quit (Ping timeout: 240 seconds)
  • [01:14:25] <zmatt> that's odd... http://pastebin.com/QZruZHhM
  • [01:15:34] <GrumpeiYokoi_> Are you C-ifying dissassembled code?
  • [01:15:37] <zmatt> yes
  • [01:16:02] <GrumpeiYokoi_> I said that right before I saw goto 0x80000000; XD
  • [01:16:08] <GrumpeiYokoi_> Wouldn't have asked otherwise
  • [01:16:26] <zmatt> yeah I was too lazy to write a proper cast for that
  • [01:16:36] <GrumpeiYokoi_> It's fine, the meaning is understood
  • [01:18:53] <zmatt> ohhhh wait a minute, that's why the gpmc config function is so tiny... various options are passed straight from sysboot pins to internal hw strapping options of the gpmc module that it uses to initialize its config regs during reset
  • [01:19:13] <zmatt> that means yes, you can use any of the modes supported by gpmc
  • [01:19:37] <zmatt> bootrom just programs the timing, which I'll check
  • [01:20:50] * bkearns (~bkearns@216-75-239-130.static.wiline.com) Quit (Quit: Leaving.)
  • [01:21:46] * Gareth (~garethFre@znc.wiked.org) has joined #beagle
  • [01:28:47] <ds2> where are you disassembling it from?
  • [01:29:18] <ds2> thought it is protected on exit from ROM
  • [01:30:13] * uavcamm (~deuse@113.118.118.246) Quit (Ping timeout: 272 seconds)
  • [01:30:36] * uavcamm (~deuse@113.118.118.246) has joined #beagle
  • [01:33:01] <zmatt> lol, this is really nicely done... http://pastebin.com/jfTFM6vy
  • [01:33:12] <zmatt> no, public rom is readable
  • [01:33:58] <zmatt> I also have a full disassembly of dm814x secrom where they blocked access to only one of the two aliases in memory ;)
  • [01:35:01] <zmatt> anyhow, it's evidently using the reset defaults of gpmc
  • [01:35:03] <ds2> heh "oops"
  • [01:35:14] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) has joined #beagle
  • [01:35:31] <zmatt> it's a terrible mess though
  • [01:35:36] <zmatt> both pubrom and secrom
  • [01:35:50] <ds2> so it boils down to breaking out about 30 traces or booting with a UART
  • [01:35:56] <zmatt> 30 traces?
  • [01:36:50] <zmatt> hmm, I suppose an external flash wouldn't support A/A/D multiplexed mode?
  • [01:37:19] <zmatt> or 16-bit A/D ?
  • [01:38:08] <zmatt> I can also check to see where that other "goto" from fastext_init() is going to
  • [01:38:25] <zmatt> because it seems it might support fastext from NAND flash provided it supports internal ECC
  • [01:38:35] <zmatt> (or you lie and claim it does and hope for the best)
  • [01:39:35] <zmatt> I never got around to implementing ECC support in my dm814x codebase and haven't got a single read error yet, ever
  • [01:39:43] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) Quit (Ping timeout: 246 seconds)
  • [01:41:08] <zmatt> hmm, nm, sysboot9 seems to do something different in the context of fastext boot
  • [01:42:36] <zmatt> ah it seems to enable wait
  • [01:43:04] <zmatt> so you could even feed it data with a uC or something silly like that (then again, you probably could even without wait)
  • [01:44:26] <ds2> 16A, 8D
  • [01:44:28] <ds2> + control
  • [01:44:48] <zmatt> non-multiplexed mode? is that really unavoidable?
  • [01:44:56] <ds2> well, maybe just 2 control... no need for R
  • [01:45:24] <ds2> is mux mode NOR's easily sourceable thesedays
  • [01:45:26] * berton (~fabio@201.22.227.56) Quit (Read error: Connection reset by peer)
  • [01:45:36] <ds2> it would trade 8 lines for an ALE
  • [01:45:57] <ds2> but if mux mode is available, 16bit roms look attractive :D
  • [01:46:55] * GrumpeiYokoi_ (~chatzilla@75-150-234-17-Illinois.hfc.comcastbusiness.net) Quit (Ping timeout: 240 seconds)
  • [01:48:20] * RobotGuy (~hybotics@ip72-220-121-210.sd.sd.cox.net) Quit (Quit: RobotGuy)
  • [01:51:44] <Mountainman> So I am having trouble with the ADC. I am using PWM to drive a motor system and the ADC to get the output voltage. I am using the PRU's. When I run the program the ADC will freeze on the last value it read and lock up requiring reboot. It only occurs it seems when the motors are running. I though it was emi from the motors so I moved them as far away as I could and still the issue persists. Does anyone have any thoughts?
  • [01:59:22] * idwer (~irc@unaffiliated/idwer) Quit (Remote host closed the connection)
  • [02:00:32] <zmatt> back... laptop decided to randomly crash
  • [02:00:45] <zmatt> ds2: then again, maybe looking at fastext is premature
  • [02:04:48] <zmatt> ds2: having fewer wires (i.e. spi flash) would probably be preferred; the big question is whether you can hook up the power supplies and provide adequate decoupling
  • [02:05:26] <zmatt> and for all interfaces you'd need to look at what's going to happen w.r.t. return currents if you lack a ground plane
  • [02:06:51] <zmatt> if you keep enough distance in all directions you may even be able to retain a high impedance and avoid significant currents entirely (woo, power savings)
  • [02:07:04] * clonak_ (~clonak@118-92-142-3.dsl.dyn.ihug.co.nz) Quit (Read error: Connection reset by peer)
  • [02:07:14] <zmatt> assuming the energy isn't turned into EMI instead, dunno about that :P
  • [02:09:23] * yogesh (7bc94ce3@gateway/web/freenode/ip.123.201.76.227) has joined #beagle
  • [02:10:08] <zmatt> ds2: oh, flex doesn't allow components on both sides... so you're looking at rigid-flex anyway
  • [02:10:28] <Mountainman> Would emi at different part of the board cause issues across the entire board? I.e. EMI from the motors closer to P9_01 causing issues along the header towards P9_36?
  • [02:10:35] <zmatt> Mountainman: that
  • [02:10:42] <zmatt> Mountainman: that's really hard to say I think
  • [02:10:46] <zmatt> in general statements
  • [02:12:18] <zmatt> what kind of protection do you have on the ADC inputs?
  • [02:12:42] <Mountainman> I just have no idea what the issue is and its driving me crazy.... it even happens if just attach the adc pins to a trim pot on a separate board. But only when the motors are running.
  • [02:13:39] <zmatt> then it sounds more like a software issue
  • [02:14:01] <Mountainman> Voltage divider and a diode. But the fact that it still happens even when the only source is VDD_ADC seems counter the idea of the adc getting messed up.
  • [02:14:06] * Devastator (~devas@177.97.254.194) has joined #beagle
  • [02:14:06] * Devastator (~devas@177.97.254.194) Quit (Changing host)
  • [02:14:06] * Devastator (~devas@unaffiliated/devastator) has joined #beagle
  • [02:14:35] <Mountainman> And if it was purely software why would it work flawlessly so long as the motors arent running?
  • [02:14:44] * clonak (~clonak@118-92-142-3.dsl.dyn.ihug.co.nz) has joined #beagle
  • [02:14:56] * Devastator_ (~devas@unaffiliated/devastator) Quit (Ping timeout: 276 seconds)
  • [02:14:58] <Mountainman> Is loki just messing with me right now?
  • [02:15:03] <zmatt> probably
  • [02:15:05] <zmatt> :)
  • [02:15:24] <zmatt> the software does not have any different control flow if the motors are running?
  • [02:16:07] <Mountainman> no. Literally all I do it pull the wire feeding Vcc to the motor controller and run the same program.
  • [02:17:01] <Set_> Do you have Pololu Motor controllers?
  • [02:17:31] <Mountainman> no just a custom setup with a lm298n
  • [02:17:39] <Set_> Oh.
  • [02:18:07] <Set_> I had to use software and additional battery support for my BBB when making my bot go and stop.
  • [02:18:09] <zmatt> Mountainman: if the program is unaware that the motors aren't running but the fact they're not running fixes the problem, then I would say we're back at electrical issues
  • [02:18:10] <ds2> zmatt: I think I have seen flex with dual side load
  • [02:18:25] <ds2> but I am more worried about getting thinenough traces to break things out
  • [02:18:54] <Set_> hey Mountain, did you do the math on everything?
  • [02:19:28] <zmatt> ds2: what about rigid-flex? lol, look at the funky thing at topleft of page 7 -> http://www.minco.com/Flex-Circuits/~/media/WWW/Resource%20Library/Flex/Minco_FullFlexDesignGuide.ashx
  • [02:19:32] * baboo (~baboo@home.tking.org) has joined #beagle
  • [02:19:32] * baboo (~baboo@home.tking.org) Quit (Changing host)
  • [02:19:32] * baboo (~baboo@unaffiliated/baboo) has joined #beagle
  • [02:19:42] <Mountainman> Set: yes, as much as I could. What in particular are you thinking
  • [02:20:23] <Set_> I just know from my notes, oh and I am not a memory wiz on engineering, that particular math is needed to make everything add up.
  • [02:20:35] <Set_> I am just saying that it may be a math conern.
  • [02:20:44] <Set_> conern = cocern
  • [02:20:53] <Set_> nevermind.
  • [02:21:14] <Set_> Let me get my notes.
  • [02:21:20] <Set_> Hold please.
  • [02:21:26] <ds2> zmatt: that stuff is a bankruptcy inducing cost
  • [02:21:32] <Mountainman> okay.
  • [02:21:35] <zmatt> ds2: hehehehe
  • [02:21:44] <zmatt> it looks really cool though
  • [02:21:48] <ds2> and there are very irritating rules - feature size is worse of rigid and flex
  • [02:21:59] <ds2> looked into that for another project
  • [02:22:32] <zmatt> yeah I see the "cost multiplier" thing
  • [02:22:44] <ds2> I'd think getting proper decoupling caps in there is going to be painful
  • [02:22:52] <zmatt> yet essential
  • [02:23:16] <ds2> maybe the experiment should be - boot MLO with a AM3359 setup deadbug style
  • [02:23:22] <ds2> using the UART of course
  • [02:23:27] <Set_> the book is called Circuits: 2nd Edition.
  • [02:24:01] <zmatt> ds2: "deadbug style" ?
  • [02:24:06] <Set_> Now Mountain, please tell me what you believe is the problem. I am sure I have some notes on it.
  • [02:24:24] <Set_> I will scroll through the pages and look it up.
  • [02:24:25] <ds2> chip with balls facing up and 30G or smaller wires going to the balls
  • [02:24:39] <Set_> Cool!
  • [02:25:17] <zmatt> Mountainman: have you put a scope probe on the lines to see whether horrible crud is perhaps being induced on the traces going to the motor circuit
  • [02:25:26] <Set_> Now...is it amplification, analog to digital conversion, and etc...
  • [02:25:27] <Set_> ?
  • [02:25:49] <zmatt> (never mind why crud on the motor lines might lock up the ADC, electrical noise works in mysterious ways)
  • [02:25:51] <Mountainman> Set: I dont know what the problem is, hence the reason I am asking everyone and the mother about it lol, I think it has something to do with the emi of the motors as the issue only seems to occur when the motors are running. If knew what the problem was I could pretty easily do the engineering to fix it i think
  • [02:26:00] <ds2> the ADC block is a sensitive block
  • [02:26:23] <zmatt> ds2: yeah but he has the probs apparently even if no connection is going from ADC to the motor circuit
  • [02:26:23] <ds2> dump the error registers in the ADC block
  • [02:26:31] <Set_> Okay...sorry. I will go back to the notes.
  • [02:26:39] <zmatt> the error was bus lockup I think
  • [02:26:43] <Set_> Be back in a jiff.
  • [02:26:44] <zmatt> iirc
  • [02:26:46] <ds2> ask the ADC what does it think it is doing. there has to eb a reason the state machine stopped iterating
  • [02:26:58] <ds2> there is a bus lock up bit?
  • [02:27:13] <zmatt> yeah, it's called "watchdog reset" :P
  • [02:27:14] <Mountainman> zmat: I dont have one unfortunately.
  • [02:27:21] <ds2> :P
  • [02:27:29] <Set_> Do you know Ohm's law and how to calculate resistance?
  • [02:27:41] * zmatt gags Set_
  • [02:27:44] <Set_> It could be simple math like that...
  • [02:27:46] <Set_> What?
  • [02:27:58] * intripoon_ (~quassel@p5DEBA97F.dip0.t-ipconnect.de) has joined #beagle
  • [02:28:17] <Set_> Oops.
  • [02:28:19] <Mountainman> Set: yes..... it isnt that. Unless the current tolerance of the pins is < 0.001nA
  • [02:28:21] <Set_> I got my deal wrong.
  • [02:28:26] <Set_> Okay.
  • [02:28:39] <Set_> Mountain...I am going back to the book.
  • [02:29:12] <Mountainman> How do I dump error registers of ADC, my knowledge of the BB subsystems is a little weak. I am using libpruio library and functions.
  • [02:29:48] <zmatt> Mountainman: so just to verify: if you leave the ADC unconnected (or better yet, tie its signals to ground or vdd_adc with short wires or resistors), and have the program running, it locks up on adc reads if the motor controller is actually powered but works fine if the motor controller is off (and the program is unaware of this fact)
  • [02:29:59] <zmatt> btw, is the motor controller okay with getting pwm signals if it's not powered?
  • [02:30:04] <zmatt> most chips aren't
  • [02:30:10] * intripoon (~quassel@p5DEBA97F.dip0.t-ipconnect.de) Quit (Ping timeout: 260 seconds)
  • [02:30:33] <Mountainman> zmatt: yes
  • [02:30:45] <Mountainman> to both.
  • [02:30:47] <zmatt> ok
  • [02:31:36] <ds2> what is the ADC reporting?
  • [02:31:40] <ds2> position or?
  • [02:31:43] <zmatt> I'd say try additional ESD/EMI protection on the motor control wires, close to the BBB
  • [02:31:53] <zmatt> ds2: well, if not connected then it's not reporting anything
  • [02:32:08] <ds2> fair enough
  • [02:32:22] <ds2> going with your reasoning, why not optically isolate the motor?
  • [02:32:32] <ds2> easier then dealing with EMI stuff
  • [02:32:43] <zmatt> assuming Mountainman has the relevant components
  • [02:32:52] <ds2> LDR + LED? :D
  • [02:32:57] <Mountainman> optically isolate?
  • [02:33:00] * nofxx (~nofxx@unaffiliated/nofxx) has joined #beaglebone
  • [02:33:06] <ds2> look up "optoisolator"
  • [02:33:41] <zmatt> Mountainman: just checking... are the ground planes of the BBB and your motor controller thoroughly connected?
  • [02:33:51] * bengo (~textual@50-203-84-2-static.hfc.comcastbusiness.net) Quit (Quit: My Mac has gone to sleep. ZZZzzz…)
  • [02:34:48] <Mountainman> zmatt: I mean they should be. All the pins ground pins are tied back together and tied to the ground on the beaglebone
  • [02:35:18] <zmatt> "all the ground pins" ... by any chance, would that be a ground pin per control signal?
  • [02:36:03] <zmatt> if so, just for fun, try running a twisted pair per signal (one wire for ground, one for the actual signal)
  • [02:36:35] <zmatt> basically to keep the BBB -> signal -> controller -> ground -> BBB loop as small as possible
  • [02:38:03] <zmatt> normally you'd run a signal trace over a ground plane for that, but when running a cable the alternative is to keep a ground wire close to the signal at all times
  • [02:38:08] <ds2> just go optical
  • [02:38:13] <zmatt> or that
  • [02:38:30] <zmatt> except that's not gonna solve the problem once he attaches the ADC again
  • [02:38:36] <ds2> why not?
  • [02:38:58] <zmatt> because it would probably pick up the same crap?
  • [02:39:16] * Akex_ (uid58281@gateway/web/irccloud.com/x-nesgqwiobiclqrkk) Quit (Quit: Connection closed for inactivity)
  • [02:39:16] <ds2> why would it?
  • [02:39:26] <zmatt> depends on the overall design I guess
  • [02:39:32] <ds2> when I say optical, I mean both PWM optical out and Optical back to the ADC
  • [02:39:46] <Mountainman> So provide additional ground wires? I am not sure I understand. I have main power, a voltage regulator, the motor driver, and an amplifier whose grounds are all connected to the same pin which leads back to the beaglebones ground. Everything takes power from the same source. The BB provides PWM, 3.3V, 5V,
  • [02:40:07] <zmatt> Mountainman: it's not specifically about the amount of ground wires
  • [02:40:15] <ds2> problem with keeping galvanic connections is all sorts of non ideal behaviors can appear
  • [02:40:17] <zmatt> but the distance between signal and ground wires
  • [02:40:29] <Mountainman> ahhh
  • [02:40:33] <ds2> you can into impedences of your connections and such
  • [02:40:37] <zmatt> ds2: optical back to the adc? care to elaborate?
  • [02:40:59] <ds2> zmatt: simpliest - have the motor drive a LED and wire up the ADC to a LDR in a divider config.
  • [02:41:11] <ds2> s/motor/motor signal/
  • [02:42:27] * zmatt glares
  • [02:42:39] * yogesh (7bc94ce3@gateway/web/freenode/ip.123.201.76.227) Quit (Quit: Page closed)
  • [02:42:44] <ds2> they make packaged optoisolators like those
  • [02:42:55] <ds2> or a phototransistor inplace of the LDR
  • [02:43:07] <Mountainman> I dont think I can reduce distance anymore than I already am. The only wires near the motor system are the motors +/- leads and the PWM signal.
  • [02:43:38] <ds2> Mountainman: are you running wires directly from the motor to the BBB?
  • [02:43:44] <Set_> You need a power source for the motor drivers and the bbb.
  • [02:43:50] <Set_> separate.
  • [02:43:56] <zmatt> apart from the bias voltage you'll need to keep the led on at all, isn't this going to be wildly non-linear and need careful calibration (and sacrifice more of the already shitty resolution of the adc)
  • [02:44:01] <zmatt> Mountainman: wait what?
  • [02:44:14] <zmatt> Mountainman: you're not powering the motor from the BBB's 5V are you?
  • [02:44:19] <ds2> if so, try putting a buffer (say a BJT) in between there
  • [02:44:46] <ds2> zmatt: sure, with the LDR... a phototransistor isn't that bad over a reasonable range
  • [02:44:53] <Set_> I had to use a power source for each motor controller and for the BBB.
  • [02:45:00] <ds2> there are plenty of simple linear optoisolators
  • [02:45:19] <ds2> even some non opto, "opto" isolators
  • [02:45:20] <zmatt> Mountainman: also, I would hope the motor's - signal is separate from the signal ground for the pwm signals
  • [02:45:45] <Mountainman> No no. Motor driver requires 5v to turn it on. Motors and all peripherals are powered from a separate UPS system. Wires are run to a board where voltage dividers and diodes are used to lower voltage and current to acceptable levels and protect pins
  • [02:46:17] <Set_> I had three power sources for the bot. The bot only had two wheels, two motor controllers, and one BBB.
  • [02:46:35] <zmatt> Mountainman: have any doc/spec of the motor controller?
  • [02:47:01] <Mountainman> its an lm298N pretty common dual full bridge.
  • [02:47:24] <Mountainman> http://www.st.com/web/en/resource/technical/document/datasheet/CD00000240.pdf
  • [02:48:35] <zmatt> "vss" for a supply pin, interesting terminology
  • [02:48:56] <Mountainman> Also what do you mean by "the motors signal is separate from the signal ground for the pwm signals"
  • [02:49:14] <zmatt> - supply I mean, but never mind that
  • [02:49:48] <zmatt> actually do mind that
  • [02:50:01] <zmatt> but then don't, since you already mentioned the motors are supplied separately
  • [02:50:01] <zmatt> :P
  • [02:50:10] <Mountainman> lol okay
  • [02:50:12] * Humpelstilzchen (erik@f054097036.adsl.alicedsl.de) Quit (Ping timeout: 255 seconds)
  • [02:50:21] <ds2> put it on a fast scope
  • [02:50:25] <ds2> bbl
  • [02:50:27] <zmatt> ds2: no scope, he mentioned that
  • [02:51:25] <Mountainman> is there a cheap at home scope I can buy? Most I see are pretty expensive....
  • [02:52:33] <Mountainman> Also i just ran the program for 20 minutes with no power and I had no issue. So I think it is definitely electrical.
  • [02:53:36] * Defiant (erik@f054114042.adsl.alicedsl.de) has joined #beagle
  • [02:53:51] <Set_> If someone was to check the voltage with a battery tester, could you connect alligator clips/wires to test the terminals and things?
  • [02:54:14] <Set_> I ask because I have seen people rig those.
  • [02:54:29] <Mountainman> yes?
  • [02:54:36] <Set_> But there needs to be a power source.
  • [02:54:36] <zmatt> Mountainman: the BBB pwm signals are probably connected directly to the motor controller?
  • [02:55:34] <Mountainman> yes?
  • [02:55:54] <Mountainman> Should they not be?
  • [02:56:01] <zmatt> Mountainman: yes they probably should
  • [02:56:22] <Mountainman> okay good.
  • [02:56:50] <Set_> How many wheels do you have/motors?
  • [02:57:03] <zmatt> ok, my main concern would be that the example diagram happily conflates the ground for the motor outputs (connected to the series resistors) with the signal ground for the inputs
  • [02:57:16] <zmatt> that feels like a bad idea
  • [02:57:52] <zmatt> Mountainman: any idea how much peak current those motors are drawing?
  • [02:58:24] <zmatt> also, are you actually using the same ground, or are you using separate grounds ?
  • [02:59:28] <zmatt> this datasheet is confusing
  • [03:00:11] <Mountainman> 2 motors coupled at the shaft. So only one being driven. Peak current idk i can check in a minute though. A decent amount though I would imagine as it is the reason I bought the lm298n. I was originally just using a bjt and it was burning out....
  • [03:00:59] <Mountainman> the actual ground pins are physically "separate" but are all connected with wires so it should be one ground.
  • [03:01:50] <zmatt> yyyeaahhsorta... especially when dealing with fast high-current transients, it matters a lot how *exactly* things are grounded
  • [03:02:04] <zmatt> also, is either the UPS or the BBB also grounded in another way?
  • [03:02:27] <zmatt> (in other words, do you have a ground loop?)
  • [03:02:44] <Mountainman> No. Like I said literally every ground is connected is connected in someway back to one singular point.
  • [03:02:51] <Set_> I have my bot in front of me. You need a ground for each motor controller.
  • [03:03:10] <Set_> Set up two grounds, one for each motor controller.
  • [03:03:11] <zmatt> Mountainman: ok, star topology of grounding is generally a good thing
  • [03:03:57] <Set_> I cannot believe you made your own motor controllers. That must have been a pain.
  • [03:04:38] <Set_> Soldering, coding, and assembly could make anyone go bonkers.
  • [03:06:38] <Mountainman> Set: the 298 motor driver IC only has 1 gnd which is connected to every other ground. And honestly it was not very hard. Just 2n2222 bjt, with motor connected to collector, pwm into base, vcc between emitter and collecter. As Pwm is high current can pass emitter to collector. But it kept burning out the bjt so I swapped it for the lm298. Essentially the same thing.
  • [03:07:01] <zmatt> Mountainman: why the bjt?
  • [03:07:23] <zmatt> ahh
  • [03:07:24] <zmatt> nm
  • [03:07:28] <zmatt> should have finished reading
  • [03:07:48] <zmatt> kept burning out the bjt... so we are talking some serious currents here
  • [03:09:15] <Mountainman> yea... the load motor is a 12v and the driving motor is a 6v. They are in gearboxs but the torque needed to actually turn the load motor means substantial current draw. Nothing ridiculous but a few amps at least.
  • [03:09:24] <Set_> Damn!
  • [03:09:40] <zmatt> I hope you used some thick wires
  • [03:10:04] <Mountainman> Oh yes. 18 gauge
  • [03:10:30] <Set_> 12VDC. Yikes!
  • [03:10:46] <zmatt> I must say I'm starting to lean more and more towards ds2's suggestion of using optocouplers for the pwm control signals
  • [03:10:46] <Set_> Is this a enormous bot?
  • [03:11:27] <zmatt> especially if you want to be able to read back the sense values via the adc... which is gonna be fun indeed
  • [03:11:40] <Set_> a.k.a hammer thrower?
  • [03:12:49] <Mountainman> haha Set it actually isnt a robot. It is sort of a small scale version of larger industrial device meant to be a learning tool for system integration and embedded systems.
  • [03:13:04] <Set_> Cool man.
  • [03:14:10] <Set_> I am only using a quadruple set of 1.5v AA batteries for my one motor controller. I have two motors and two motor controllers.
  • [03:14:16] <zmatt> without that second part, I would say: make sure the wire between pin 8 of the l298 (which seems to be the signal ground) and the BBB does not share a common segment with the ground for the motor outputs (i.e. different branches of the star), and keep that ground (from pin 8 of the l298) and the pwm signals closely together to the BBB
  • [03:14:44] <Mountainman> zmatt: I feel like the optocouplers would just make things more difficult. If there is not direct connection i feel like it would be more susceptible to emi and such. Plus wouldnt there be accuracy issues?
  • [03:15:16] <zmatt> Mountainman: optical isolation is actually very common in motor control
  • [03:15:27] <zmatt> for pwm there shouldn't be any issues, just use fast enough optos
  • [03:15:43] <zmatt> but you can try what I mentioned above first
  • [03:15:48] <zmatt> but it doesn't combine with ADC readback
  • [03:15:59] <zmatt> at least not easily I think
  • [03:16:03] <zmatt> it might still
  • [03:17:38] <Mountainman> So going back to what you said above, DONT have motor controller ground share a ground with the actual motor itself?
  • [03:18:12] * j0rd_ (~j0rd_@unaffiliated/j0rd-/x-9112651) Quit (Read error: Connection reset by peer)
  • [03:18:19] <zmatt> I think it needs to share it, if I understand the l298 right
  • [03:18:52] <Mountainman> yea it does. It wont run if they arent tied together.
  • [03:19:01] <zmatt> dangit I wish I could easily draw circuit diagrams
  • [03:19:14] * florian__ (~fuchs@Maemo/community/contributor/florian) has joined #beagle
  • [03:19:20] * j0rd_ (~j0rd_@unaffiliated/j0rd-/x-9112651) has joined #beagle
  • [03:19:43] * CrazyEddy (crazyed@wrongplanet/CrazyEddy) Quit (Remote host closed the connection)
  • [03:19:57] <uavcamm> papaer and pen @zmatt ;)
  • [03:20:00] <Mountainman> It takes practice.
  • [03:20:09] <zmatt> but basically you want the ground to be one straight line: BBB - motor driver (signal ground) - motor driver (output ground) - motor supply
  • [03:20:35] <Mountainman> I wish I could post a picture....
  • [03:20:48] <zmatt> BBB has an isolated supply I'm assuming? (an AC adapter probably)
  • [03:20:53] <zmatt> I also hope _no_ usb connection
  • [03:21:10] <zmatt> or serial
  • [03:21:15] <zmatt> or really anything except ethernet :P
  • [03:21:16] <Mountainman> ..... ehhhh mini usb to usb for power and communication via ssh
  • [03:21:27] <Mountainman> no bueno?
  • [03:21:30] <zmatt> ok, so now your BBB is grounded to your computer
  • [03:22:01] <Mountainman> If all the grounds are tied to the bbb would that make a huge difference?
  • [03:22:22] <Mountainman> Also could it possible be interference from the motor controller and not the motors?
  • [03:22:24] <zmatt> could still be okay if the motor psu is completely isolated from any grounds
  • [03:23:10] * florian_kc (~fuchs@Maemo/community/contributor/florian) Quit (Ping timeout: 276 seconds)
  • [03:24:41] <zmatt> but if possible, replace the usb by ethernet + an ungrounded psu (i.e. a typical AC adapter, 5V 2A output)
  • [03:24:55] <zmatt> ethernet is transformer-isolated
  • [03:25:23] <zmatt> ditto the AC adapter, so that avoids any unforeseen ground currents
  • [03:25:36] <zmatt> not saying it's necessary, but put it on your list of things to try
  • [03:25:58] <Mountainman> sigh... I really hope that isnt necessary. I already cut holes and internally wired my enclosure ):
  • [03:26:22] <zmatt> before everything was tested as working? :P
  • [03:26:25] * CrazyEddy (crazyed@wrongplanet/CrazyEddy) has joined #beagle
  • [03:26:36] <Mountainman> Well it was working before on the prototype.....
  • [03:26:48] <zmatt> interesting, what's the diff?
  • [03:27:07] <Set_> If you have only two wires coming from your motor (one motor), you can connect four wires to your motor controller, i.e. VIN, outA, outB, and GND. Oh and you can use your power source for the motor controller to ground your motor controller. Heh?
  • [03:27:30] <zmatt> I still support my statement though, no sane person would use USB in an industrial environment
  • [03:27:43] <Set_> Yea...
  • [03:27:47] <zmatt> so if this proto is an example, maybe start by setting a good example ;)
  • [03:28:02] <zmatt> isolation ftw
  • [03:28:07] <Set_> Still, it will work for his smaller item that is a replica of a larger industrial machine.
  • [03:28:18] <Mountainman> idk... honestly. I thought it was the PWM. When I tested the adc functionality on the prototype I used a constant 5v source to power the motor system.
  • [03:28:34] <zmatt> Mountainman: it's hard to say at this point
  • [03:28:54] <Set_> I will break while you all figure out something. I will keep thinking.
  • [03:29:16] <zmatt> Mountainman: but first, are you sure there's no connection between your grounds and any protective ground / earth ?
  • [03:29:20] <zmatt> other than via usb
  • [03:30:14] <Mountainman> But since the adc doesnt have an issue with pwm on its own i kind of ruled that out. Yea the whole thing is in an antistatic budbox. The kind used for like outdoor power boxes.
  • [03:30:31] <zmatt> and the motor supply is isolated?
  • [03:31:01] <zmatt> (sorry for possibly asking things I already asked, just want to be sure)
  • [03:31:17] <Set_> All I can say now is I would need a file tree of current that takes place. "A" to "B" and "B" to "C" and etc...
  • [03:32:12] <zmatt> Mountainman: if no loops exist, then make sure the ground is a nice linear path I outlined earlier
  • [03:33:08] <Mountainman> I mean the motor supply ground is tied to the other grounds. But it wont work otherwise
  • [03:36:14] * Nico44 (~Nico44@82.67.127.241) has joined #beagle
  • [03:36:57] <Set_> I say separate but equal.
  • [03:37:04] <zmatt> ok I'm gonna try making a crappy outline
  • [03:37:04] <Mountainman> is there a place I can just upload a picture for a few seconds?
  • [03:37:14] <zmatt> probably...
  • [03:37:17] <Set_> Separate those grounds.
  • [03:38:09] <Set_> Um...there is google docs.
  • [03:38:14] <zmatt> good one
  • [03:38:29] <Set_> I think those work. Even if it is a small drawing.
  • [03:38:40] <Set_> Freehand!
  • [03:39:50] <Set_> Or...Friting.
  • [03:40:03] <Set_> Sorry...Fritzing.
  • [03:40:28] * Nico44 (~Nico44@82.67.127.241) Quit (Ping timeout: 246 seconds)
  • [03:41:28] <Set_> Um...conceptboard may work.
  • [03:42:38] <zmatt> fritzing ... that I can try indeed, Dia really sucks
  • [03:42:49] * dj_pi (~dj@c-73-191-212-56.hsd1.mi.comcast.net) has joined #beagle
  • [03:43:05] <zmatt> iirc fritzing was pretty limited but at least worked sanely
  • [03:43:33] <Set_> I found a schematic tool a while back. I will look it up again. I will try to remember.
  • [03:44:20] <zmatt> yeah thing I never draw schems normally
  • [03:44:44] <Set_> instructions on how to build H-Bridges from MOSFETS or BJT’s are available online in many places. Many companies sell H-Bridge IC’s, sometimes with more than one bridge and often including additional sensor and control lines for the motor.
  • [03:44:58] <zmatt> Set_: he's using such an ic
  • [03:45:25] <Set_> I have no clue what IC is. I am lacking common sense.
  • [03:45:38] <Set_> I found that in my notes. I forgot totally.
  • [03:45:55] <zmatt> grab a dictionary
  • [03:45:59] <Set_> I have a lot to look up to keep up with you fellows.
  • [03:47:29] <Set_> I just went to BBB.org and found Upverter.
  • [03:47:36] <Set_> I think they have a free developer account.
  • [03:48:12] * jevin (~jevin@72.12.217.220) has joined #beagle
  • [03:49:03] <Set_> Hey, while he looks up how to clone what he has already done...can you explain how I check pitch on terminals.
  • [03:49:05] <Set_> Please?
  • [03:49:51] <Set_> I am sure there is some tool. I just do not want to hunker down and get it.
  • [03:50:02] <Mountainman> https://docs.google.com/document/d/1pSzPOC_GBRoIij6tTimj7jjISsepYetm9sZGHyAV9N8/edit
  • [03:50:08] <Mountainman> can yall access that?
  • [03:50:18] <Set_> I will see.
  • [03:50:53] <Set_> All those alpha-numeric characters looks like my mttq:// location tool for uploading to a specific site.
  • [03:50:54] * jevin_ (~jevin@72.12.217.220) Quit (Ping timeout: 260 seconds)
  • [03:52:09] * praneeth (praneeth@nat/ti/x-ziavngxbsgbzonhn) Quit (Remote host closed the connection)
  • [03:52:32] * praneeth (praneeth@nat/ti/x-noqeronvaodboayj) has joined #beagle
  • [03:52:45] <zmatt> Mountainman: you need to do File -> Share -> advanced -> "Anyone who has the link can..." set to "comment"
  • [03:53:21] * dj-pi (~dj@c-73-191-212-56.hsd1.mi.comcast.net) has joined #beagle
  • [03:53:51] <Mountainman> try it now https://docs.google.com/document/d/1pSzPOC_GBRoIij6tTimj7jjISsepYetm9sZGHyAV9N8/edit?usp=sharing
  • [03:54:48] <Mountainman> sorry if it looks like shit.
  • [03:55:35] <Set_> The file does not exist.
  • [03:55:42] <Set_> That is what I got.
  • [03:56:55] <zmatt> works for me now
  • [03:57:00] <Set_> Dang...
  • [03:57:02] <Mountainman> says there are two anonymous peeps viewing it
  • [03:57:07] <Set_> Um...
  • [03:57:10] <Set_> Not me.
  • [03:57:23] <Set_> I will try again.
  • [03:57:25] <uavcamm> i tried. but the great firwall blocks the actual access..
  • [03:57:38] * dj_pi (~dj@c-73-191-212-56.hsd1.mi.comcast.net) Quit (Ping timeout: 276 seconds)
  • [03:58:27] <Mountainman> I mean i cant share it anymore than it is. says 3 anonymous people are viewing it
  • [03:59:06] <zmatt> Mountainman: btw, it's "L298", not "LM298" ... I found nothing on that latter part code
  • [03:59:26] <zmatt> (the datasheet you linked to also says L298 )
  • [03:59:37] <Mountainman> ahhh sorry by bad
  • [03:59:58] <Set_> I got a google Docs thing.
  • [04:00:10] <Set_> It was Google I/O coding school or something.
  • [04:00:18] <Set_> Weird.
  • [04:00:20] <Mountainman> wut...
  • [04:00:52] <Set_> Yep.
  • [04:00:55] <zmatt> Mountainman: and stop drawing ground like there's the Big All-Encompassing 0Ω-impedance Ground you can connect to at your whim... the actual grounding matters :P
  • [04:01:18] * uavcam (~deuse@174.139.64.86) has joined #beagle
  • [04:01:39] <Mountainman> Sorry the reason I did that is because I connected all the ground pins together. I can redraw it
  • [04:01:51] <zmatt> Mountainman: they should be, but it matters *how*
  • [04:01:58] * uavcamm (~deuse@113.118.118.246) Quit (Ping timeout: 260 seconds)
  • [04:02:51] <Set_> If you have four connections from your power, you can add battery, VIN, Out, Out2, and Ground to exactly one motor control.
  • [04:03:25] <zmatt> Mountainman: the bottom part is a "zoom-in
  • [04:03:39] <zmatt> " of the (M) of the middle-diagram ?
  • [04:03:49] <zmatt> no wait, different part number
  • [04:03:54] <Set_> It would be like a four way with three items.
  • [04:04:04] <zmatt> now sure what I'm looking at then
  • [04:04:41] * Phagus (~Phagus@209.195.114.239) has joined #beaglebone
  • [04:04:42] * Phagus (~Phagus@209.195.114.239) has left #beaglebone
  • [04:04:47] * tai271828 (~tai271828@111.248.104.52) Quit (Quit: Leaving)
  • [04:05:00] <zmatt> ok, fritzing also gets on my nerves, and debian mispackaged it
  • [04:05:04] <Mountainman> no first is driving motor connected to motor controller l298, second is load motor conected to divider. I didnt draw shaft coupling
  • [04:05:24] * Phagus (~Phagus@209.195.114.239) has joined #beagle
  • [04:05:35] <zmatt> ah, "load motor" meaning generator here
  • [04:05:37] <zmatt> ?
  • [04:05:38] <Phagus> What's the maximum side of microsd card on a BBB?
  • [04:05:48] <zmatt> Phagus: size you mean?
  • [04:06:08] <Phagus> I tried to write Arch Linux ARM to a 64gb microSD card, and it didn't see to want to boot from it
  • [04:06:15] <zmatt> ah for boot
  • [04:06:16] <zmatt> hmm
  • [04:06:21] * magra (manisha@nat/ti/x-evhvpmqgstngmise) Quit (Remote host closed the connection)
  • [04:06:33] <Mountainman> yea generator
  • [04:06:41] * magra (manisha@nat/ti/x-eygqdhtqpiyswero) has joined #beagle
  • [04:06:45] <uavcam> fritzing is broken in sid
  • [04:07:01] <Phagus> I'm following this guide: http://archlinuxarm.org/platforms/armv7/ti/beaglebone-black
  • [04:07:16] * Liir (~francky@pool-108-26-190-11.bstnma.fios.verizon.net) Quit (Quit: This computer has gone to sleep)
  • [04:08:37] <Phagus> zmatt: Do you know if 64gb is too big for boot?
  • [04:09:22] <zmatt> I don't see any reason why it would be
  • [04:10:02] <zmatt> those instructions don't make sense to me though
  • [04:12:10] <zmatt> according to the TRM an sd card needs a FAT boot partition, the "raw mmc" method (u-boot at fixed offset) supposedly only works for eMMC, not for cards, though I haven't verified myself whether that's actually true
  • [04:13:13] <zmatt> but there's afaik no magic limit around 64 GB .. the only magic limit is at 4 GB
  • [04:14:21] <zmatt> the comments near the bottom of the instructions also suggests arch deals pretty crappy with the eMMC devices :P
  • [04:14:29] <zmatt> stuff like that has been solved in uptodate debian images
  • [04:17:57] <zmatt> Mountainman: in any case, give my suggestion a shot of making sure the ground connections are BBB -- L298 pin 8 -- motor ground -- motor supply
  • [04:18:20] <zmatt> Mountainman: leaving the adc out of the equation for now, since you have the lockups also if it's not connected so first focus on that
  • [04:20:35] * Phagus (~Phagus@209.195.114.239) Quit (Ping timeout: 272 seconds)
  • [04:20:41] <zmatt> the ground from BBB to L298 pin 8, hereby declared "signal ground", is also the return ground for the pwm signals so keep those close together
  • [04:21:14] <Mountainman> okay.
  • [04:21:54] <zmatt> preferably use twisted pairs (harvest from some CAT5 cable) for each pwm signal, with the wire it's twisted with connected to signal ground on both ends
  • [04:22:13] <zmatt> that minimizes the possibility of those lines picking up crap
  • [04:22:29] * cybernaut (~cyberman@72-161-243-87.dyn.centurytel.net) Quit (Quit: Leaving)
  • [04:23:38] <Mountainman> Hold the phone how do the ADC pins look internally? Like do they draw current easily?
  • [04:24:16] <zmatt> see AM335x datasheet
  • [04:24:26] <zmatt> also see AM335x errata!
  • [04:24:35] <zmatt> but that's mostly a concern during power-up
  • [04:24:46] <zmatt> (the erratum)
  • [04:26:10] <zmatt> and add schottky diodes as voltage clamps just in case
  • [04:26:44] <zmatt> (reminder that the adc is only 1.8V )
  • [04:26:45] <Mountainman> okay cause I just tested it again and it is magically working again. However with a caveat, the generator motor is powering a small light. When the adc is connected the light does not illuminate anymore hinting that the adc is drawing all the current.
  • [04:27:15] <zmatt> the adc should not draw significant current normally
  • [04:27:26] <zmatt> especially not since you have 10K in series
  • [04:27:34] <zmatt> oh wait
  • [04:27:39] <zmatt> is that a K ?
  • [04:27:44] <zmatt> yes it is
  • [04:28:21] * Phagus (~Phagus@209.195.114.239) has joined #beagle
  • [04:28:35] <Phagus> Bah dcdd
  • [04:28:46] <Mountainman> hmm okay so the output is 12v. The light bulb has a resistance of 35 ohms. The Adc has a voltage divider with a total series resistance of 11.73k. So the current that goes to the adc pin should be < current through bulb by simple nodal analysis....
  • [04:29:35] <zmatt> Phagus: you can also get BBBlfs from github, ignore its crappy scripts but compile its poorly named "usb_flasher" tool
  • [04:29:51] <Mountainman> So now the adc works, but the bulb will not illuminate. Could the previous issue have been a current issue in the adc pins?
  • [04:29:51] <zmatt> Phagus: power up the BBB with no sd card inserted but SD-boot button held
  • [04:30:11] <zmatt> Phagus: connect to usb, it'll show up as a network interface (rndis)
  • [04:30:19] * MichaelLong (~ml@p4FF25180.dip0.t-ipconnect.de) Quit (Remote host closed the connection)
  • [04:30:37] <zmatt> Phagus: bring up the interface (happens automatically if you use NetworkManager, but you might not be)
  • [04:30:47] <zmatt> Phagus: then run the "usb_flasher" tool from BBBlfs
  • [04:31:21] <Mountainman> and now it isnt working anymore.....
  • [04:31:24] * MichaelLong (~ml@p4FF251EC.dip0.t-ipconnect.de) has joined #beagle
  • [04:31:32] * dj-pi (~dj@c-73-191-212-56.hsd1.mi.comcast.net) Quit (Ping timeout: 272 seconds)
  • [04:31:44] <zmatt> Phagus: wait a bit, if all goes well it'll show some progress as it boots the BBB into a tiny linux system that makes the eMMC accessible as mass storage device
  • [04:32:19] <zmatt> Phagus: once it's done, the BBB's eMMC appears as /dev/sdX and you can try the installation procedure directly to eMMC
  • [04:32:31] <zmatt> skipping the SD card altogether
  • [04:33:05] <zmatt> since you're apparently an arch user, I'll assume you can take it from there :P
  • [04:33:43] <zmatt> the usb_flasher tool, although quite useful, is also quite brittle and seems to rely on initialization already being done by the linux rndis driver
  • [04:33:51] <zmatt> hence the need to bring up the interface
  • [04:34:51] <zmatt> alternative you can configure dnsmasq to act as BOOTP + TFTP server to accomplish the same thing as the usb_flasher tool (USB boot of the BBB works by appearing as RNDIS device and then attempting to netboot from the host)
  • [04:35:24] <Phagus> Getting a little ahead of myself here. Just trying to figure out what this boot button does
  • [04:35:29] <zmatt> changes the boot order
  • [04:35:31] <Phagus> rather, how it works, when to press it
  • [04:35:38] <zmatt> hold it during power-up
  • [04:35:45] <zmatt> (note: not mere reset, power-up. )
  • [04:35:58] <Phagus> So its turned on right now from earlier. I press the power off button to shut it off
  • [04:36:16] <Phagus> Then I remove the power cable, and plug the cable back in and hold the boot button?
  • [04:36:44] * tws2172 (~tws2172@cpe-75-185-169-190.neo.res.rr.com) has joined #beagle
  • [04:37:00] <zmatt> hold the boot button while plugging in the cable
  • [04:37:18] <Phagus> Should I turn it off first?
  • [04:37:30] <zmatt> yes, by unplugging :P
  • [04:37:48] <zmatt> clean shutdown isn't very important probably if you don't have a working system yet
  • [04:38:15] <zmatt> note that long-pressing the power button will power-cycle or power-off depending on circumstances
  • [04:38:20] <Phagus> Well, I read it can damage it
  • [04:38:31] <Phagus> and I'm triyng to get into good habits early on :-)
  • [04:39:03] <zmatt> if you don't have a running linux system that listens to the power button event and performs a clean shutdown, then you can't perform a clean shutdown anyway
  • [04:39:09] <zmatt> u-boot ignores it
  • [04:39:38] <zmatt> and the power-cycle/power-off triggered by long-pressing it isn't really much cleaner than a power cut.... well okay maybe a little
  • [04:39:51] <Phagus> How long do I hold boot button for?
  • [04:40:03] <zmatt> note that it'll probably power-cycle, so you can long-press the power button while holding down the SD-button
  • [04:40:06] <zmatt> 8 secs iirc
  • [04:40:15] <Mountainman> Okay so another test, the ADC only locks if the pin is connected for an extended period of time. I.E. if I plug the cable in an unplug it doesnt freeze, also I cant have it connected when it first starts up..
  • [04:40:16] <zmatt> you notice it since the power led goes off
  • [04:40:27] * tws2172 (~tws2172@cpe-75-185-169-190.neo.res.rr.com) Quit (Client Quit)
  • [04:41:26] <zmatt> after 1 sec it'll either power on by itself or if you are still/again holding the power button
  • [04:41:56] <zmatt> this is sufficiently "off" for the SD-button to take effect, so no physical unplugging needed
  • [04:42:05] <Phagus> So while I put the power cable in, I hold boot button?
  • [04:42:20] <Phagus> or I put power cable in first, then hold boot button?
  • [04:42:28] <Phagus> Sorry, this is a bit unclear :-P
  • [04:42:39] <zmatt> you hold it pressed while the system powers on, whether due to cable plug-in or due to pressing the power button
  • [04:43:02] <zmatt> i.e. the SD-button state is sampled roughly around the time the power led turns on
  • [04:43:28] <zmatt> (SD-button, boot button, "S2", all synonyms... sorry for not being consistent :P )
  • [04:43:52] <Phagus> Its okay. Just trying to seriously figure this thing out
  • [04:44:07] <Phagus> The LEDs seem pretty unresponsive to the boot button
  • [04:44:13] <zmatt> they are
  • [04:44:20] <zmatt> power button != boot button
  • [04:44:26] <Phagus> Yes
  • [04:44:51] <Phagus> So I plugged in cable, held boot button for 8 seconds, and the LEDs are just flashing as they always have
  • [04:45:06] <Phagus> going to go check fi my image was loaded
  • [04:45:12] <zmatt> ok sorry if I confused you
  • [04:45:31] <Phagus> Its cool. Pretty friendly community here at #beagle :-)
  • [04:46:06] <zmatt> the power button (nearest to the ethernet connector) only influences power: it works roughly like you'd expect a power button to behave: if the system is off it turns it on, if the system is on it generates an event the OS can react to
  • [04:46:44] <Phagus> I was reading that the power button also initiates shutdown
  • [04:46:52] <zmatt> if you keep it pressed for a long time the system is supposed to power-cycle (power-off, followed 1 second later by a power-on), although due to technical reasons it often results in power-off instead
  • [04:47:10] <zmatt> long time being around 8 seconds, although it's not very precise
  • [04:48:13] <zmatt> if the system doesn't boot into linux then most likely it'll power-cycle rather than power-off
  • [04:48:34] <Phagus> Cool
  • [04:49:06] <zmatt> the system also powers on if a power supply is plugged in
  • [04:49:49] <Phagus> How long did it take you to learn BBB to the point of comfort btw?
  • [04:49:54] <zmatt> at power-on (regardless of why it powered on) it samples 16 pins to determine its boot config
  • [04:50:07] <zmatt> these are set to sensible defaults using 100K resistors
  • [04:50:45] <zmatt> but you can override them if you want to via pins on expansion header P8 (the ones labeled lcd_data0-15)
  • [04:51:00] <zmatt> the boot-button (nearest to the μSD slot) also overrides one of them
  • [04:51:30] <zmatt> (specifically it pulls sysboot2 to ground with a 100Ω resistor)
  • [04:51:45] <zmatt> the net effect is that it changes the boot device order
  • [04:51:59] <zmatt> default is { eMMC, μSD, uart, usb }
  • [04:52:18] <zmatt> with SD boot-button held it becomes { spi, μSD, usb, uart }
  • [04:52:43] <zmatt> this is essentially similar to changing your boot device order in BIOS, just a bit more crude ;)
  • [04:52:54] <zmatt> and more suitable for things that don't necessarily have a GUI
  • [04:53:31] <Phagus> Hmm that method didn't work
  • [04:53:36] <Phagus> Debian is still installed
  • [04:53:37] <zmatt> the pins are only sampled at power-up, their value after that is ignored
  • [04:53:50] <Phagus> I mean
  • [04:53:52] <zmatt> so you need to make sure the boot-button is held down during power up
  • [04:53:53] <Phagus> Still booted up
  • [04:54:10] <Phagus> How should I shut down my device right now then?
  • [04:54:24] <zmatt> try briefly pressing the power button
  • [04:55:22] <zmatt> reminder: power button = right next to ethernet, SD-boot button = near SD card slot
  • [04:55:28] <zmatt> the latter one is an easy mnemonic
  • [04:55:42] <Phagus> Oh yes I have the locations down
  • [04:55:46] <zmatt> ok
  • [04:56:00] <Phagus> So to power it back up
  • [04:56:06] <Phagus> I hit power button then boot button?
  • [04:56:08] <zmatt> it powered down indeed?
  • [04:56:09] <zmatt> no
  • [04:56:14] <zmatt> hold boot button down
  • [04:56:17] <Phagus> Yeah no LEDs flshig
  • [04:56:26] <zmatt> all leds off?
  • [04:56:37] <Phagus> ys
  • [04:56:45] <zmatt> hold boot button down, keep it held down
  • [04:56:52] <zmatt> then trigger a power-up
  • [04:56:54] <Phagus> Ok
  • [04:57:01] <Phagus> I'm like 15 secs into holding bot
  • [04:57:12] <zmatt> like I said, the state of the boot button is sampled right around the time the power led goes on
  • [04:57:18] <zmatt> so you need to have it pressed down before that
  • [04:57:23] <zmatt> and can let go once the power led goes on
  • [04:58:44] <Phagus> I'm holding it down.. It doesnt seem to cause the thing to power on
  • [04:58:55] <zmatt> by itself it doesn't
  • [04:59:00] <zmatt> you need to press the power button to turn it on
  • [04:59:15] <Phagus> So with the device turned off, I hold the boot button down for 8 seconds
  • [04:59:18] <zmatt> no
  • [04:59:31] <Phagus> Okay....
  • [04:59:37] <Phagus> Well, I powered it off before and its still in the off state
  • [04:59:41] <zmatt> read what I said a few lines ago
  • [04:59:49] <uavcam> hold the button while you power it on and release it after the power led turns on
  • [04:59:51] <zmatt> "the state of the boot button is sampled right around the time the power led goes on"
  • [05:00:02] <zmatt> the boot button doesn't *do* anything by itself
  • [05:00:16] <zmatt> but its state it checked by the processor when it's powered on
  • [05:00:34] <zmatt> hence... what uavcam just said
  • [05:02:16] <zmatt> you can power it on using the power-button (if power is plugged in) or plugging in power (if it isn't)
  • [05:05:36] <Phagus> This isn't working
  • [05:05:52] <zmatt> then just pull the plug
  • [05:05:59] <Phagus> No no no
  • [05:06:00] <Phagus> I did that
  • [05:06:10] <zmatt> but it's still booting?
  • [05:06:14] <zmatt> btw, did you eject the SD card?
  • [05:06:15] <Phagus> I pulled the plug out, I kept the boot button held down while I put the power back in
  • [05:06:28] <Phagus> No, I dont know when to eject the SD card
  • [05:06:35] <zmatt> right now, and keep it that way
  • [05:06:58] <Phagus> What about my Arch image?
  • [05:07:22] <zmatt> first check that the sd boot thingy is working (noticable by the BBB *not* booting from eMMC)
  • [05:07:33] <Phagus> Oh sorry, it is
  • [05:07:38] <Phagus> I shjould mention that I'm constnatly SSHing in
  • [05:07:58] <Phagus> If I see "BeagleBoard Debian Image" on the SSH welcome screen, I know my image hasnt been loaded
  • [05:08:18] <zmatt> yeah, so if you the boot-button-thing without any SD card, it shouldn't boot at all
  • [05:08:28] <zmatt> since eMMC is taken out of the boot order and no SD card is inserted
  • [05:08:32] <Phagus> Oh ok
  • [05:08:34] <zmatt> verify that first
  • [05:08:36] <Phagus> Let me try that yes
  • [05:08:53] <Phagus> I should tip you after this lol
  • [05:09:09] * Sandhya (~schmid@2a02:8070:a192:2f00:226:5aff:febc:ce5f) has joined #beagle
  • [05:09:46] <zmatt> so the expected state is power led turning on, and then nothing
  • [05:09:54] <zmatt> other leds stay off
  • [05:10:13] <Phagus> ok so all LEDs are off now
  • [05:10:23] <Phagus> Now I press boot button?
  • [05:10:38] <zmatt> just checking: are you powering via USB connection to a computer, or using an AC adapter?
  • [05:10:43] <Phagus> ac
  • [05:11:00] <zmatt> ok, then all boot methods are failing now so it'll keep cycling through them till it finds one that works
  • [05:11:19] <Phagus> Well all the lights are off right now
  • [05:11:22] <zmatt> so if you want you can insert the SD card to try it
  • [05:11:37] <zmatt> you may need to wait a few seconds
  • [05:11:49] <Phagus> The thing is, out of the box, BBB is preloaded with a debian image on the eMMC thing
  • [05:12:01] <zmatt> yeah, but eMMC is out of the boot order right now
  • [05:12:38] <zmatt> if it still boots into debian, then the bootloader you programmed onto your SD card actually boots linux from eMMC
  • [05:12:41] <zmatt> or
  • [05:12:55] <zmatt> it loads your arch kernel, but passes the wrong kernel args and ends up using eMMC as rootfs
  • [05:13:14] <zmatt> isn't it fun, having so many options :)
  • [05:13:25] <Phagus> Yeah I'm still not getting the whole boot button thing
  • [05:13:37] <Phagus> ight now BBB is plugged in but no LEDs
  • [05:13:42] <zmatt> the boot button merely tells ROM where to look for the stage 1 bootloader
  • [05:13:45] <Phagus> I held down boot button and no LEDs lit up
  • [05:14:18] <zmatt> like I said, it's like the BIOS config menu on a PC where you can decide the order in which various boot disks are examined
  • [05:14:19] <Phagus> I put in SD card, no lights again. with SD still placed inside I held down boot button, device is still not flashing any LEDs
  • [05:14:24] <Phagus> Yeah
  • [05:14:36] <Phagus> So its like hitting f4 or whatever right at boot?
  • [05:14:42] <Phagus> f4/del/f8/etc
  • [05:15:00] <zmatt> yeah, except the processor just looks at whether it's pressed or not right at power-on
  • [05:15:05] <uavcam> right
  • [05:15:07] <zmatt> (about 25 ms after the power led turns on)
  • [05:15:22] <zmatt> (iirc)
  • [05:15:22] <Phagus> So I need to have button held down before I even turn it on
  • [05:15:26] <zmatt> yes
  • [05:15:29] <uavcam> they should used a jumper...
  • [05:15:30] <zmatt> and you can let go immediately after
  • [05:15:32] <Phagus> This is hard
  • [05:15:35] <zmatt> uavcam: you can
  • [05:15:39] <Phagus> I wish I had two more arms
  • [05:15:48] <zmatt> Phagus: but you're in the right state right now
  • [05:15:51] <zmatt> so keep it that way
  • [05:16:07] <Mountainman> Phagus: I wish everyday that I had 4 arms.... or telekinesis or some shit.
  • [05:16:39] <Phagus> Four arms + TK, I'll take that
  • [05:16:48] <zmatt> uavcam: you can connect a resistor between P8.43 and ground, has the same effect as pressing the boot button
  • [05:17:05] <zmatt> I have a little jumper wire with a resistor in it for exactly that purpose :)
  • [05:17:21] <Phagus> YESssssssssssssss it works
  • [05:17:26] <Phagus> Okay cool
  • [05:17:32] <Phagus> You're my saviour here zmatt
  • [05:18:01] <Phagus> I seriously will tip you for this, lol
  • [05:18:08] <zmatt> Phagus: note that if you want to use BBBlfs (which is a very useful tool to have in your toolbox), the procedure is similar, but instead of inserting an SD card, connect it to USB
  • [05:19:30] <zmatt> I can also strongly recommend getting a serial console cable if you don't already have one... it's never fun to be blind when having boot issues
  • [05:20:06] <zmatt> Phagus: btw, define "it works" ... did it actually boot from the card?
  • [05:20:16] <Phagus> serial cable = miniUSB-to-USB cable?
  • [05:20:19] <zmatt> no
  • [05:20:27] <Phagus> ethernet cable?
  • [05:20:32] <zmatt> http://elinux.org/Beagleboard:BeagleBone_Black_Serial
  • [05:20:35] <zmatt> I mean serial
  • [05:20:41] <Phagus> Oh interesting
  • [05:20:55] <Mountainman> hey so I am still having issues with the adc. It only happens when the pin is connected for certain time and when it is connected it draws current from the load. If I connect and disconnect it continually it never freezes. Any ideas on a solution?
  • [05:21:00] <Phagus> it works = I SSHed into the arch image having been loaded
  • [05:21:26] <Phagus> Interesting
  • [05:21:37] <zmatt> Phagus: that's fascinating... means the AM335x TRM is wrong
  • [05:21:37] <Phagus> I've seen one of these before
  • [05:22:25] <zmatt> Phagus: so apparently a FAT boot partition isn't needed for SD cards either, didn't know that
  • [05:22:30] <zmatt> since your card doesn't have one, right?
  • [05:23:13] <Phagus> Ahh... I'm not sure
  • [05:23:25] <zmatt> btw, tip: those installation instructions put the ext4 partition at 1 MB from start of disk (sector 2048)
  • [05:23:33] <zmatt> put it at 4 MB from start (sector 81920
  • [05:23:33] <uavcam> the tutorial looks like there is none
  • [05:23:51] <zmatt> since 4 MB is the erase-block size of the eMMC
  • [05:24:23] * skhreze (~debian@ip-5-172-247-197.free.aero2.net.pl) has joined #beagle
  • [05:24:43] <zmatt> hence starting a partition at 1 MB is effectively "misaligned"
  • [05:25:19] <zmatt> I think for performance tuning there's also some ext4 option to tell it the raid stripe size is 4 MB (never mind it's not raid, that's apparently still the best way to inform it)
  • [05:26:57] <zmatt> Phagus: btw, another fun fact about the power button: it is incapable of waking the system from suspend
  • [05:27:17] <zmatt> brilliant little hardware design screw-up
  • [05:27:40] <zmatt> the interrupt signal from the pmic is wired to a pin that's not capable of waking up the system
  • [05:28:30] <Phagus> I see
  • [05:28:57] <Phagus> lol my lab is a mess.
  • [05:29:10] <zmatt> you can wake it up in a ton of other ways, just not the power button
  • [05:30:23] <Phagus> uname on my ssh, confirmed to be ARCH armv7l
  • [05:30:28] <zmatt> woo
  • [05:30:40] <zmatt> congrats... I guess ;P
  • [05:30:55] <Phagus> 4.3.0-1-ARCH
  • [05:31:00] <Phagus> eah Im following the part 2 now
  • [05:31:01] <zmatt> ok, so not a -ti kernel
  • [05:31:07] <Phagus> You were asaying something earlier about part 2
  • [05:31:10] <zmatt> so you don't have working power management anyway
  • [05:31:23] <zmatt> (probably)
  • [05:31:37] <zmatt> yeah the steps 4 and 5 sound quite odd
  • [05:31:58] <zmatt> but the root cause is that linux enumerates mmc devices in whatever order is happens to encounter them
  • [05:32:22] <Phagus> TI made their own kernel?
  • [05:32:31] <zmatt> it doesn't care that the hardware and bootloader always consider the μSD slot to be mmc0 and eMMC to be mmc1
  • [05:32:47] <zmatt> they have a branch with patches that haven't made it to mainline yet
  • [05:33:21] <zmatt> no shock there, most distros also use branches of the kernel with their own patches
  • [05:33:46] <Phagus> Well, yeah. I just would have thought they had stroger control over the BBB upstream I guess?
  • [05:33:59] <zmatt> debian systems normally use kernels with beaglebone-specific patches ("-bone" kernels) and optionally also the TI patches ("-ti" kernels)
  • [05:34:00] <Phagus> or maybe arch-arm made some uncanny dev decisions
  • [05:34:13] <zmatt> lately the -ti kernels are default on bbb debian systems
  • [05:34:18] <zmatt> they simply work better atm
  • [05:34:28] <zmatt> however there's no 4.3-ti kernel :)
  • [05:34:50] * vagrantc (~vagrant@unaffiliated/vagrantc) has joined #beagle
  • [05:34:54] <Phagus> Oh yes, welcome to Arch Linux's bleeding edge philosophy ;-)
  • [05:34:55] <zmatt> for some reason they were stuck at 4.1 for a while, and recently I spotted a 4.4-rc1-ti kernel
  • [05:35:19] <zmatt> I'm all for bleeding edge
  • [05:35:41] <zmatt> except bleeding edge mainline may still lag behind 4.1-ti when it comes to hardware support specific to TI processors
  • [05:35:55] <zmatt> so then you have to choose which edge you consider more important
  • [05:36:45] <Phagus> I mean, if you have valid criticism against Arch-Arm on BBB, by all means let me hear it. I'm not wedded to the idea of using it
  • [05:36:55] <zmatt> "nobody uses it"
  • [05:37:03] <zmatt> if you ask questions here, you'll run into that problem
  • [05:37:05] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) has joined #beagle
  • [05:37:08] <Phagus> I do like the customizability Arch gives me. I'm planning on using this BBB as a stripped-down appliance
  • [05:37:10] <zmatt> virtually everyone runs debian
  • [05:37:21] <Phagus> I see
  • [05:37:29] <Phagus> How about this Angstrom thing?
  • [05:37:36] <zmatt> museum piece
  • [05:37:36] <uavcam> acient
  • [05:38:02] <Phagus> I think I'll do that then
  • [05:38:06] <zmatt> lol
  • [05:38:09] <Phagus> I'm sure I will encounter problems
  • [05:38:17] <Phagus> So Debian it is
  • [05:38:20] <zmatt> Phagus: since you're used to arch, consider debian sid
  • [05:38:29] <zmatt> otherwise you'll be OMG WTF IS ALL THIS ANCIENT CRAP
  • [05:38:32] <zmatt> alll the time
  • [05:38:54] <Phagus> Oh nah, I have Debian servers still running Wheezy
  • [05:39:02] <zmatt> ew
  • [05:39:37] <zmatt> Phagus: I don't use anything older than stretch myself
  • [05:40:14] <zmatt> there are no premade stretch images, but it's easy enough to download the latest jessie console image and then directly upgrade to stretch
  • [05:41:34] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) Quit (Ping timeout: 246 seconds)
  • [05:42:15] <zmatt> what I was saying about "step 2" earlier
  • [05:42:58] <zmatt> the last two points on the page (4 and 5) sound like mess that has been solved in the debian images
  • [05:43:04] <Phagus> Will I encounter lag issues with Debian?
  • [05:43:12] <Phagus> I mean, I don't need a lot of preinstalled things Debian normally comes with
  • [05:43:20] <zmatt> linux enumerates mmc devices in whatever order it encounters them
  • [05:43:23] <uavcam> just get the minimal images
  • [05:43:54] <zmatt> so hardcoded root=/dev/mmcblk0p1 will cause trouble
  • [05:44:00] <zmatt> debian switched to using UUID
  • [05:44:17] <Phagus> For eg, I don't konw f'n Java runtime do I?
  • [05:44:23] <Phagus> None of my apps use Java
  • [05:44:26] <zmatt> Phagus: grab a "console" image
  • [05:44:31] <zmatt> those are really minimal
  • [05:45:00] * baboo (~baboo@unaffiliated/baboo) Quit (Quit: Leaving)
  • [05:46:01] <zmatt> https://rcn-ee.com/rootfs/bb.org/testing/2015-11-21/console/
  • [05:46:19] * tai271828 (~tai271828@175.41.48.77) has joined #beagle
  • [05:46:27] <Phagus> These are small
  • [05:46:46] <zmatt> the BBB-eMMC-flasher-*-.img.xz is something you can xzcat right onto your SD card, boot from it and it'll reflash your eMMC
  • [05:48:50] * skhreze (~debian@ip-5-172-247-197.free.aero2.net.pl) Quit (Ping timeout: 240 seconds)
  • [05:57:27] <Phagus> Thanks
  • [05:57:31] <Phagus> Doing these things.
  • [05:58:25] * vagrantc (~vagrant@unaffiliated/vagrantc) Quit (Ping timeout: 240 seconds)
  • [06:03:06] <zmatt> Phagus: there are still some unnecessary packages though, but it's *reasonably* clean
  • [06:03:27] <zmatt> you can right away purge any packages with "dra7xx" in the package name
  • [06:03:54] <zmatt> ditto tiomapconf
  • [06:04:50] <Phagus> Alright
  • [06:06:14] * dgilmore (~dgilmore@fedora/dgilmore) Quit (Ping timeout: 260 seconds)
  • [06:06:44] <Phagus> Okay, I think its flashing
  • [06:07:01] <Phagus> I see the lights moving in an ordered fashion, 1,2,3,4,3,2,1
  • [06:07:01] <Phagus> etc
  • [06:07:05] <zmatt> yes that's flashing
  • [06:07:12] <zmatt> all leds on = done
  • [06:08:07] <zmatt> I'm currently nosing around in the same image to see what's there (except I couldn't be bothered to flash it so I'm using systemd-nspawn to browse it)
  • [06:08:36] <Phagus> You've been extremely helpful zmatt
  • [06:08:44] <zmatt> qemu does seem to make some things a bit laggier, although disk I/O is obviously snappier than eMMC
  • [06:08:47] <Phagus> Seriously, at the very least I owe you a beer
  • [06:08:56] <zmatt> heh, I don't drink beer but thanks :)
  • [06:09:22] <Phagus> Haha. Or whatever.
  • [06:09:32] <Phagus> Cool so I think that did it
  • [06:11:44] <Phagus> yepp
  • [06:12:22] <Phagus> we in busnierss. So quick question. Can you just patch into a BBB without a router?
  • [06:12:30] <Phagus> using an ethernet cable
  • [06:12:42] <zmatt> it expects a dhcp server
  • [06:12:50] <zmatt> you can change that to static config of course
  • [06:13:10] <zmatt> also popular is usbnet (that's enabled by default in the big images but not in the console image)
  • [06:14:16] <zmatt> note that if you feel like ditching the old ifupdown and use systemd-networkd instead (I did and consider it an improvement) you need to upgrade to stretch first since jessie's systemd is too old
  • [06:14:17] <uavcam> plugin the cable, get a static ip in the same net and you should be able to connect
  • [06:14:29] <zmatt> uavcam: "without a router"
  • [06:14:43] <zmatt> Phagus: actually, it'll still be reachable via ipv6 in any case of course
  • [06:14:49] * dgilmore (~dgilmore@fedora/dgilmore) has joined #beagle
  • [06:14:55] <zmatt> yay for stateless ip autoconfiguration
  • [06:15:18] <zmatt> what the hell is dmidecode doing on an arm system
  • [06:15:30] <zmatt> lol
  • [06:17:29] * BennyB_ (~heldb@host-88-217-198-167.customer.m-online.net) has joined #beagle
  • [06:18:06] <uavcam> yeah without a router. just connect two devices with a cable and they should be able to communicate via ethernet without any router/switch/hub/whatever inbetween if the ip conf is right
  • [06:25:11] * dgilmore (~dgilmore@fedora/dgilmore) Quit (Ping timeout: 276 seconds)
  • [06:26:01] * dgilmore (~dgilmore@fedora/dgilmore) has joined #beagle
  • [06:37:38] * bengo (~textual@c-98-210-158-252.hsd1.ca.comcast.net) has joined #beagle
  • [06:45:41] * kiwichris (~kiwichris@msc1401703.lnk.telstra.net) Quit (Ping timeout: 246 seconds)
  • [06:49:48] * bizarro_1 (~bizarro_1@140.Red-2-138-29.dynamicIP.rima-tde.net) Quit (Quit: Leaving)
  • [06:57:59] * natsurou (~natsurou@181.67.95.17) Quit (Read error: Connection reset by peer)
  • [06:59:26] * roric (~roric@h196n19-vrr-a31.ias.bredband.telia.com) has joined #beagleboard
  • [06:59:26] * roric (~roric@h196n19-vrr-a31.ias.bredband.telia.com) has joined #beaglebone
  • [07:01:33] * natsurou (~natsurou@200.121.211.229) has joined #beagle
  • [07:05:29] * tomeff (~tomeff@ip-78-102-111-158.net.upcbroadband.cz) has joined #beagle
  • [07:05:30] * tomeff (~tomeff@ip-78-102-111-158.net.upcbroadband.cz) has joined #beagleboard
  • [07:05:30] * tomeff (~tomeff@ip-78-102-111-158.net.upcbroadband.cz) has joined #beaglebone
  • [07:09:45] * kiwichris (~kiwichris@CPE-60-225-146-35.hhui6.ken.bigpond.net.au) has joined #beagle
  • [07:09:46] * nofxx (~nofxx@unaffiliated/nofxx) Quit (Ping timeout: 240 seconds)
  • [07:12:06] * natsurou (~natsurou@200.121.211.229) Quit (Ping timeout: 255 seconds)
  • [07:12:38] * jpirko (~jirka@jirka.pirko.cz) has joined #beagle
  • [07:19:58] * NulL` (~bleh1@87.254.64.125) has joined #beagle
  • [07:20:30] * vmayoral (~vmayoral@208.Red-79-150-62.dynamicIP.rima-tde.net) has joined #beagle
  • [07:22:11] * roric (~roric@h196n19-vrr-a31.ias.bredband.telia.com) Quit (Ping timeout: 252 seconds)
  • [07:23:10] * tomeff (~tomeff@ip-78-102-111-158.net.upcbroadband.cz) Quit (Quit: tomeff)
  • [07:25:07] * vmayoral (~vmayoral@208.Red-79-150-62.dynamicIP.rima-tde.net) Quit (Ping timeout: 250 seconds)
  • [07:37:53] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) has joined #beagle
  • [07:42:19] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) Quit (Ping timeout: 246 seconds)
  • [07:48:01] * linkedinyou (~linkediny@unaffiliated/linkedinyou) has joined #beagle
  • [07:48:01] * linkedinyou (~linkediny@unaffiliated/linkedinyou) has joined #beaglebone
  • [08:00:13] <ozzloy> i'm gettin https://www.refheap.com/112053 on my beaglebone black booted with the image from http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_console it's unclear to me what i should do. how do i get that executable?
  • [08:00:54] <ozzloy> how do i get the executable arm-linux-gnueabihf-gcc
  • [08:01:59] * citylight2 (~me@84.111.153.0) Quit (Ping timeout: 264 seconds)
  • [08:04:49] * rob_w (~bob@93.104.205.194) has joined #beagle
  • [08:04:49] * rob_w (~bob@93.104.205.194) Quit (Changing host)
  • [08:04:49] * rob_w (~bob@unaffiliated/rob-w/x-1112029) has joined #beagle
  • [08:06:50] <tbr> whate are you trying to do?
  • [08:09:01] * vmayoral (~vmayoral@208.Red-79-150-62.dynamicIP.rima-tde.net) has joined #beagle
  • [08:14:33] * Mounicq (~Thunderbi@130.230.21.109.rev.sfr.net) has joined #beagle
  • [08:16:03] * jamesaxl (~jamesaxl@41.140.204.124) Quit (Remote host closed the connection)
  • [08:17:50] * khem (~khem@unaffiliated/khem) Quit (Ping timeout: 240 seconds)
  • [08:20:14] * khem (~khem@unaffiliated/khem) has joined #beagle
  • [08:20:55] * lyakh (~lyakh@xdsl-87-78-163-66.netcologne.de) has joined #beagle
  • [08:20:58] * tomeff (~tomeff@ip-89-176-75-234.net.upcbroadband.cz) has joined #beagle
  • [08:20:58] * tomeff (~tomeff@ip-89-176-75-234.net.upcbroadband.cz) has joined #beagleboard
  • [08:20:58] * tomeff (~tomeff@ip-89-176-75-234.net.upcbroadband.cz) has joined #beaglebone
  • [08:21:11] * NulL` (~bleh1@87.254.64.125) Quit (Ping timeout: 264 seconds)
  • [08:21:47] * Phagus (~Phagus@209.195.114.239) Quit (Ping timeout: 264 seconds)
  • [08:22:18] * florian__ is now known as florian
  • [08:30:03] * citylight2 (~me@bzq-218-29-26.cablep.bezeqint.net) has joined #beagle
  • [08:31:46] * Yotson (~Yotson@2001:980:6ac8:1:109d:328d:c5d5:d68c) has joined #beagle
  • [08:35:26] * ppisati (~ppisati@2-230-238-136.ip204.fastwebnet.it) has joined #beagle
  • [08:49:50] * Phagus (~Phagus@209.195.114.239) has joined #beagle
  • [08:56:40] <uavcam> are you trying to compile something?
  • [08:57:27] <uavcam> or better: what software are you trying to setup?
  • [09:00:57] <Set_> Element14 had that fellow Jkrinder on the site making presentations yesterday.
  • [09:02:12] <Set_> Here it is: http://www.element14.com/community/docs/DOC-78585/l/beaglebone-black-webinar-series?ICID=hp-top10download-ban
  • [09:02:26] <Set_> Cool!
  • [09:04:53] <Set_> It said be careful before sharing but I thought twice. Enjoy.
  • [09:11:02] <tbr> jk essentially _is_ bb.org
  • [09:12:28] <Set_> Oh.
  • [09:15:20] * linkedinyou (~linkediny@unaffiliated/linkedinyou) Quit (Read error: Connection reset by peer)
  • [09:22:14] * Guest26779 (~kona@rrcs-24-153-134-93.sw.biz.rr.com) Quit (Ping timeout: 260 seconds)
  • [09:22:57] * Mountainman (48d1e307@gateway/web/freenode/ip.72.209.227.7) Quit (Ping timeout: 246 seconds)
  • [09:22:58] * Akex_ (uid58281@gateway/web/irccloud.com/x-srbchceneykufrvl) has joined #beagle
  • [09:25:11] * clonak (~clonak@118-92-142-3.dsl.dyn.ihug.co.nz) Quit (Read error: Connection reset by peer)
  • [09:26:23] * kona (~kona@rrcs-24-153-134-93.sw.biz.rr.com) has joined #beagle
  • [09:26:34] * kona is now known as Guest7854
  • [09:34:06] * clonak (~clonak@203.96.206.228) has joined #beagle
  • [09:37:19] * uavcam (~deuse@174.139.64.86) Quit (Ping timeout: 265 seconds)
  • [09:38:46] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) has joined #beagle
  • [09:40:26] * mythos (~mythos@unaffiliated/mythos) Quit (Ping timeout: 260 seconds)
  • [09:43:25] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) Quit (Ping timeout: 246 seconds)
  • [09:54:32] * citylight2 (~me@bzq-218-29-26.cablep.bezeqint.net) Quit (Ping timeout: 272 seconds)
  • [09:54:56] * citylight2 (~me@bzq-218-29-26.cablep.bezeqint.net) has joined #beagle
  • [09:57:51] * thunder5 (~user@194.66.32.1) has joined #beagle
  • [10:08:10] * RoyBellingan (~roy@195.189.129.21) has joined #beagle
  • [10:09:58] * micges_ (~micges@83.20.66.87) has joined #beaglebone
  • [10:09:58] * micges_ (~micges@83.20.66.87) has joined #beagle
  • [10:13:34] * micges (~micges@83.23.60.92) Quit (Ping timeout: 250 seconds)
  • [10:13:39] * micges_ is now known as micges
  • [10:22:11] * nighty-_ (~nighty@p12125-ipngn2601marunouchi.tokyo.ocn.ne.jp) Quit (Quit: Disappears in a puff of smoke)
  • [10:24:32] * thunder5 (~user@194.66.32.1) Quit (Quit: Leaving)
  • [10:26:34] * Phagus (~Phagus@209.195.114.239) Quit (Ping timeout: 250 seconds)
  • [10:45:50] * MichaelLong (~ml@p4FF251EC.dip0.t-ipconnect.de) Quit (Ping timeout: 276 seconds)
  • [10:53:52] * j0rd_ (~j0rd_@unaffiliated/j0rd-/x-9112651) Quit (Read error: Connection reset by peer)
  • [10:55:18] * j0rd_ (~j0rd_@unaffiliated/j0rd-/x-9112651) has joined #beagle
  • [11:00:04] * Shadyman (~matthew@unaffiliated/shadyman) Quit (Quit: Leaving.)
  • [11:07:54] * Set_ (~Set_@ip70-189-47-143.lf.br.cox.net) Quit (Ping timeout: 255 seconds)
  • [11:11:54] <zmatt> cool, I can almost sort of boot a bbb console image in an systemd-nspawn container (implicitly using qemu-user)
  • [11:12:20] <zmatt> there's just the, ehm, slight issue of qemu-user not support netlink sockets
  • [11:12:26] <zmatt> *supporting
  • [11:18:11] * rayhan (b25bfd57@gateway/web/freenode/ip.178.91.253.87) has joined #beagle
  • [11:18:15] <rayhan> hi
  • [11:18:36] <rayhan> can anybody help me with installing fswebcam on beaglebone
  • [11:18:38] <rayhan> ?
  • [11:19:55] * rayhan (b25bfd57@gateway/web/freenode/ip.178.91.253.87) Quit (Client Quit)
  • [11:39:42] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) has joined #beagle
  • [11:44:10] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) Quit (Ping timeout: 246 seconds)
  • [11:53:50] * mythos (~mythos@unaffiliated/mythos) has joined #beagle
  • [11:54:50] * Liir (~francky@pool-108-26-190-11.bstnma.fios.verizon.net) has joined #beagle
  • [12:06:11] * Ceriand|desktop1 (~Ceriand@unaffiliated/ceriand) Quit (Quit: Leaving.)
  • [12:26:48] <bradfa> zmatt: that google doc of the subarctic pins with all the tabs is quite nice :)
  • [12:29:27] <bradfa> only thing that would be nice to add would be pinctrl addresses, as those are nice for reference when doing dts creating/modification
  • [12:37:06] * Liir (~francky@pool-108-26-190-11.bstnma.fios.verizon.net) Quit (Quit: This computer has gone to sleep)
  • [12:49:16] * nicksydney_ (~quassel@232.132.dsl.syd.iprimus.net.au) Quit (Remote host closed the connection)
  • [12:49:53] * j0rd_ (~j0rd_@unaffiliated/j0rd-/x-9112651) Quit (Read error: Connection reset by peer)
  • [12:54:10] * bengo (~textual@c-98-210-158-252.hsd1.ca.comcast.net) Quit (Quit: My Mac has gone to sleep. ZZZzzz…)
  • [12:56:52] * bengo (~textual@c-98-210-158-252.hsd1.ca.comcast.net) has joined #beagle
  • [12:58:24] * Liir (~francky@pool-108-26-190-11.bstnma.fios.verizon.net) has joined #beagle
  • [12:58:26] <zmatt> 0x800 + 4 * pin
  • [12:59:08] <zmatt> for dts, use a macro
  • [13:02:22] * berton (~fabio@201.22.227.56) has joined #beagle
  • [13:02:40] <zmatt> e.g. this is what a dts fragment looks like in our codebase -> http://pastebin.com/SuR8h7hk
  • [13:08:24] * j0rd_ (~j0rd_@unaffiliated/j0rd-/x-9112651) has joined #beagle
  • [13:09:18] * Sandhya (~schmid@2a02:8070:a192:2f00:226:5aff:febc:ce5f) Quit (Remote host closed the connection)
  • [13:09:50] * idwer (~irc@unaffiliated/idwer) has joined #beagle
  • [13:10:48] * bengo (~textual@c-98-210-158-252.hsd1.ca.comcast.net) Quit (Quit: My Mac has gone to sleep. ZZZzzz…)
  • [13:13:08] * bengo (~textual@c-98-210-158-252.hsd1.ca.comcast.net) has joined #beagle
  • [13:13:42] * zacdev (~zacdev@unaffiliated/zacdev) has joined #beagle
  • [13:13:42] * zacdev (~zacdev@unaffiliated/zacdev) has joined #beaglebone
  • [13:14:30] * idwer (~irc@unaffiliated/idwer) Quit (Ping timeout: 260 seconds)
  • [13:17:01] * Liir (~francky@pool-108-26-190-11.bstnma.fios.verizon.net) Quit (Quit: This computer has gone to sleep)
  • [13:20:34] * idwer (~irc@unaffiliated/idwer) has joined #beagle
  • [13:25:58] * bengo (~textual@c-98-210-158-252.hsd1.ca.comcast.net) Quit (Quit: My Mac has gone to sleep. ZZZzzz…)
  • [13:27:08] * citylight2 (~me@bzq-218-29-26.cablep.bezeqint.net) Quit (Quit: Leaving)
  • [13:30:38] * vmayoral (~vmayoral@208.Red-79-150-62.dynamicIP.rima-tde.net) Quit (Remote host closed the connection)
  • [13:36:40] * bostondriver (~mcambria@68.128.155.223) has joined #beagle
  • [13:40:34] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) has joined #beagle
  • [13:41:20] * vmayoral (~vmayoral@208.Red-79-150-62.dynamicIP.rima-tde.net) has joined #beagle
  • [13:44:48] * ReInfo (93a380e0@gateway/web/freenode/ip.147.163.128.224) has joined #beagle
  • [13:44:55] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) Quit (Ping timeout: 246 seconds)
  • [13:44:56] <ReInfo> hi all
  • [13:45:09] <ReInfo> I have a question
  • [13:45:25] <ReInfo> somebody can answer me?
  • [13:46:05] <ReInfo> About analog input of beagleboard green
  • [13:46:30] <ReInfo> is there anyone?
  • [13:47:48] * ReInfo (93a380e0@gateway/web/freenode/ip.147.163.128.224) Quit (Client Quit)
  • [13:49:02] <tbr> EPATIENCE
  • [13:54:51] * Liir (~francky@pool-108-26-190-11.bstnma.fios.verizon.net) has joined #beagle
  • [14:03:14] * j0rd_ (~j0rd_@unaffiliated/j0rd-/x-9112651) Quit (Ping timeout: 272 seconds)
  • [14:05:30] * yegorich (d5d163ca@gateway/web/freenode/ip.213.209.99.202) has joined #beagle
  • [14:13:34] <wmat> tbr: that error crashed his IRC client I guess ;)
  • [14:21:18] * tai271828 (~tai271828@175.41.48.77) Quit (Quit: Leaving)
  • [14:23:32] * emeb (~ericb@ip68-2-68-52.ph.ph.cox.net) has joined #beagle
  • [14:24:30] * calculus (~calculus@gentoo/user/calculus) Quit (Ping timeout: 260 seconds)
  • [14:25:02] * j0rd_ (~j0rd_@unaffiliated/j0rd-/x-9112651) has joined #beagle
  • [14:25:05] * calculus (~calculus@gentoo/user/calculus) has joined #beagle
  • [14:25:05] * ChanServ sets mode +o calculus
  • [14:29:16] * nerienna (~nerienna@p5491F01F.dip0.t-ipconnect.de) has joined #beagle
  • [14:32:29] * pheonix (0e8ba0e7@gateway/web/freenode/ip.14.139.160.231) has joined #beagle
  • [14:34:05] <pheonix> Hey I'm new, but I'd like to contribute to your organisation, can someone please guide me along
  • [14:35:24] <pheonix> ?
  • [14:37:52] <tbr> what would you like to do?
  • [14:42:26] * linkedinyou (~linkediny@unaffiliated/linkedinyou) has joined #beagle
  • [14:42:26] * linkedinyou (~linkediny@unaffiliated/linkedinyou) has joined #beaglebone
  • [14:43:07] * pheonix_ (0e8ba0e7@gateway/web/freenode/ip.14.139.160.231) has joined #beagle
  • [14:44:16] <pheonix_> i would like choose Beagleboard.org for gsoc so what should i do ?
  • [14:44:36] * pheonix (0e8ba0e7@gateway/web/freenode/ip.14.139.160.231) Quit (Ping timeout: 246 seconds)
  • [14:45:19] <pheonix_> ?
  • [14:46:17] <tbr> look at the project ideas page
  • [14:46:47] <tbr> look at the gsoc student handbook how to develop from an idea or create your own idea
  • [14:48:36] <pheonix_> Thank you tbr
  • [14:53:55] * tomeff (~tomeff@ip-89-176-75-234.net.upcbroadband.cz) Quit (Ping timeout: 240 seconds)
  • [14:54:58] * vmayoral_ (~vmayoral@208.Red-79-150-62.dynamicIP.rima-tde.net) has joined #beagle
  • [14:55:00] * vmayoral (~vmayoral@208.Red-79-150-62.dynamicIP.rima-tde.net) Quit (Read error: No route to host)
  • [14:56:06] <pheonix_> I would like to do a project using Beagle board,but my mentor is asking me to do it using an arduino.can someone suggest a project for a beginner which can only be done using a beagle board and not using an arduino
  • [14:58:44] * Liir (~francky@pool-108-26-190-11.bstnma.fios.verizon.net) Quit (Ping timeout: 265 seconds)
  • [14:59:45] * Liir (~francky@pool-108-26-190-11.bstnma.fios.verizon.net) has joined #beagle
  • [15:03:19] <pheonix_> I have done many projects using arduino and would like to start with Beagle can you suggest some beginner projects that can only be done using beagle and not using an arduino
  • [15:05:03] * pheonix_ slaps pheonix_ around a bit with a large fishbot
  • [15:05:24] * pheonix_ slaps pheonix_ around a bit with a large fishbot
  • [15:10:52] * zacdev (~zacdev@unaffiliated/zacdev) Quit (Quit: zacdev)
  • [15:12:46] * rob_w (~bob@unaffiliated/rob-w/x-1112029) Quit (Quit: Leaving)
  • [15:13:27] * j0rd__ (~j0rd_@unaffiliated/j0rd-/x-9112651) has joined #beagle
  • [15:14:00] * pheonix_ (0e8ba0e7@gateway/web/freenode/ip.14.139.160.231) Quit (Ping timeout: 246 seconds)
  • [15:15:26] * j0rd_ (~j0rd_@unaffiliated/j0rd-/x-9112651) Quit (Ping timeout: 272 seconds)
  • [15:26:33] * cybernaut (~cyberman@72-161-243-87.dyn.centurytel.net) has joined #beagle
  • [15:41:27] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) has joined #beagle
  • [15:42:32] * Vasco_O is now known as Vasco
  • [15:46:01] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) Quit (Ping timeout: 246 seconds)
  • [15:49:39] * florian (~fuchs@Maemo/community/contributor/florian) Quit (Quit: Client exiting)
  • [15:50:57] * frv_ (~frV@home.miradou.com) Quit (Ping timeout: 255 seconds)
  • [15:57:00] * frv_ (~frV@home.miradou.com) has joined #beagle
  • [15:58:54] * BennyB_ (~heldb@host-88-217-198-167.customer.m-online.net) Quit (Ping timeout: 260 seconds)
  • [16:09:39] * yegorich (d5d163ca@gateway/web/freenode/ip.213.209.99.202) Quit (Ping timeout: 246 seconds)
  • [16:13:10] * vmayoral_ (~vmayoral@208.Red-79-150-62.dynamicIP.rima-tde.net) Quit (Ping timeout: 240 seconds)
  • [16:14:06] * plp1z (cf628cbb@gateway/web/freenode/ip.207.98.140.187) has joined #beagle
  • [16:14:33] * tomeff (~tomeff@ip-78-102-111-158.net.upcbroadband.cz) has joined #beagle
  • [16:14:33] * tomeff (~tomeff@ip-78-102-111-158.net.upcbroadband.cz) has joined #beagleboard
  • [16:14:33] * tomeff (~tomeff@ip-78-102-111-158.net.upcbroadband.cz) has joined #beaglebone
  • [16:14:50] * plp1z (cf628cbb@gateway/web/freenode/ip.207.98.140.187) Quit (Client Quit)
  • [16:16:36] * vmayoral (~vmayoral@208.Red-79-150-62.dynamicIP.rima-tde.net) has joined #beagle
  • [16:24:10] * vagrantc (~vagrant@unaffiliated/vagrantc) has joined #beagle
  • [16:29:27] * rob_w (~rob@unaffiliated/rob-w/x-1112029) has joined #beagle
  • [16:30:02] * bkearns (~bkearns@216-75-239-130.static.wiline.com) has joined #beagle
  • [16:31:06] * mythos (~mythos@unaffiliated/mythos) Quit (Ping timeout: 260 seconds)
  • [16:31:36] * jamesaxl (~jamesaxl@adsl196-168-23-217-196.adsl196-9.iam.net.ma) has joined #beagle
  • [16:34:35] * Exwife (0e8ba0e7@gateway/web/freenode/ip.14.139.160.231) has joined #beagle
  • [16:38:47] * johanhenselmans (~localadmi@pretsense.xs4all.nl) Quit (Ping timeout: 252 seconds)
  • [16:38:48] * johanhenselmans_ (~localadmi@pretsense.xs4all.nl) has joined #beagle
  • [16:41:32] <Exwife> I have done projects with arduino and i'm new to beagleboard.Can someone help me get started
  • [16:43:09] <wmat> Exwife: http://beagleboard.org/getting-started
  • [16:44:50] <Exwife> @wmat Tah]
  • [16:45:21] * skhreze (~debian@ip-5-172-247-255.free.aero2.net.pl) has joined #beagle
  • [16:49:12] * Exwife (0e8ba0e7@gateway/web/freenode/ip.14.139.160.231) Quit (Ping timeout: 246 seconds)
  • [17:03:17] * Yogesh (db5bfaa4@gateway/web/freenode/ip.219.91.250.164) has joined #beagle
  • [17:08:15] * nofxx (~nofxx@unaffiliated/nofxx) has joined #beaglebone
  • [17:08:25] * MichaelLong (~ml@p54907CA0.dip0.t-ipconnect.de) has joined #beagle
  • [17:09:42] * uwe__ is now known as uwe_
  • [17:11:04] * Yogesh (db5bfaa4@gateway/web/freenode/ip.219.91.250.164) Quit (Quit: Page closed)
  • [17:15:40] * tomeff (~tomeff@ip-78-102-111-158.net.upcbroadband.cz) Quit (Read error: Connection reset by peer)
  • [17:19:49] * florian (~fuchs@Maemo/community/contributor/florian) has joined #beagle
  • [17:24:41] * tomeff (~tomeff@ip-78-102-111-158.net.upcbroadband.cz) has joined #beagle
  • [17:24:41] * tomeff (~tomeff@ip-78-102-111-158.net.upcbroadband.cz) has joined #beagleboard
  • [17:24:41] * tomeff (~tomeff@ip-78-102-111-158.net.upcbroadband.cz) has joined #beaglebone
  • [17:30:03] * alexanderhiam (~alexander@216.151.180.84) has joined #beagle
  • [17:40:21] * ppisati (~ppisati@2-230-238-136.ip204.fastwebnet.it) Quit (Quit: leaving)
  • [17:42:20] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) has joined #beagle
  • [17:43:58] * skhreze (~debian@ip-5-172-247-255.free.aero2.net.pl) Quit (Ping timeout: 244 seconds)
  • [17:45:05] * eFfeM (~frans@c73189.upc-c.chello.nl) has joined #beagle
  • [17:46:22] * bostondriver (~mcambria@68.128.155.223) Quit (Ping timeout: 272 seconds)
  • [17:46:38] * NulL` (~bleh1@87.254.64.125) has joined #beagle
  • [17:46:46] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) Quit (Ping timeout: 246 seconds)
  • [17:48:09] * skhreze (~debian@ip-5-172-247-199.free.aero2.net.pl) has joined #beagle
  • [18:05:59] <xer0x_> why is my beagle so picky about booting?
  • [18:09:30] * lyakh (~lyakh@xdsl-87-78-163-66.netcologne.de) Quit (Quit: thanks, bye)
  • [18:18:03] * bizarro_1 (~bizarro_1@204.Red-79-153-177.dynamicIP.rima-tde.net) has joined #beagle
  • [18:23:56] * xer0x_ is now known as xer0x
  • [18:26:09] <tbr> xer0x: why are you so vague about your problem
  • [18:26:53] <xer0x> tbr: partially because the problem is vaguely in my head
  • [18:27:46] * Akex_ (uid58281@gateway/web/irccloud.com/x-srbchceneykufrvl) Quit (Ping timeout: 240 seconds)
  • [18:27:53] <tbr> so you don't know which part fails? or if its sd or emmc?
  • [18:28:11] * nerienna (~nerienna@p5491F01F.dip0.t-ipconnect.de) Quit (Remote host closed the connection)
  • [18:28:17] * Akex_ (uid58281@gateway/web/irccloud.com/x-ynqjesbjyqxqrbik) has joined #beagle
  • [18:28:18] <xer0x> More specifically, I wanted to flash a new OS onto my BBK's internal memory but my BBK doesn't like booting from the emmc
  • [18:28:35] * nerienna (~nerienna@p5491F01F.dip0.t-ipconnect.de) has joined #beagle
  • [18:28:54] <xer0x> I can hold down the button and boot up with what's on the SD, then copy that over
  • [18:29:08] <xer0x> but it then it won't boot it
  • [18:29:37] <xer0x> I've been trying this headless which hasn't helped debug it either :(
  • [18:32:10] * alexanderhiam (~alexander@216.151.180.84) Quit (Ping timeout: 240 seconds)
  • [18:32:45] * alexanderhiam (~alexander@216.151.180.84) has joined #beagle
  • [18:34:57] * Mounicq (~Thunderbi@130.230.21.109.rev.sfr.net) Quit (Quit: Mounicq)
  • [18:36:55] <veremit> xer0x .. have you tried downloading a Flasher image from the official page at http://elinux.org/Beagleboard:BeagleBoneBlack_Debian ?
  • [18:37:10] * vmayoral (~vmayoral@208.Red-79-150-62.dynamicIP.rima-tde.net) Quit (Remote host closed the connection)
  • [18:37:24] <veremit> I suggest the 2015-11-03 section a good starting point
  • [18:37:35] <xer0x> veremit yes, i could get that one to work
  • [18:38:05] <xer0x> then i got cocky and started to try other projects like Alpine linux
  • [18:38:41] * NishanthMenon (~nmenon@pool-71-170-163-35.dllstx.fios.verizon.net) Quit (Quit: I am a very redundant person.)
  • [18:38:42] <veremit> you'll have to refer to their documentation as to how to flash other linuxes to it
  • [18:39:04] <veremit> its not quite as simple as 'boot and copy'
  • [18:42:07] * rkc (6a331899@gateway/web/freenode/ip.106.51.24.153) has joined #beagle
  • [18:42:47] <rkc> hi All
  • [18:44:09] <rkc> any idea how to enable bootup logs on console on latest TI BSP kernel
  • [18:45:05] * NulL`` (~bleh1@80.65.242.82) has joined #beagle
  • [18:46:59] * NulL` (~bleh1@87.254.64.125) Quit (Ping timeout: 264 seconds)
  • [18:49:27] * skhreze_ (~debian@ip-5-172-247-226.free.aero2.net.pl) has joined #beagle
  • [18:50:54] <veremit> rkc .. do you have a serial debug cable to attach to the header? a lot of information comes up there ...
  • [18:51:24] * skhreze (~debian@ip-5-172-247-199.free.aero2.net.pl) Quit (Ping timeout: 255 seconds)
  • [18:54:00] <rkc> @veremit... oh yes, and it was working fine
  • [18:54:29] <rkc> but recently I switched to TI kernel, there it does not
  • [18:54:39] <rkc> I have a thread going on, here:
  • [18:54:57] <rkc> https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/IaFR3VueUrk
  • [18:54:59] <veremit> ah.
  • [18:55:16] <rkc> just got a reply from Robert Nelson
  • [18:55:36] * veremit peers at the nicklist ..
  • [18:55:44] <veremit> nope, ok cool :]
  • [18:56:32] <rkc> with omap2plus_defconfig it works fine.... this new serial driver change has switched from ttyO0 to ttyS0
  • [18:57:36] <rkc> But he seems to suggest that bootup logs will be available on ttyO0 and later on with getty we should use ttyS0
  • [18:57:43] <rkc> strange !!!
  • [18:57:55] <rkc> unless I missed his point
  • [19:02:40] <veremit> no .. the serial port using the 8250 driver will appear as ttyS0
  • [19:02:54] <veremit> only the omap driver still uses the legacy ttyO0
  • [19:03:15] <veremit> how uboot handles it I'm not sure
  • [19:03:28] <veremit> but the physical port should be the same ..
  • [19:07:26] * Yogesh (db5bfaa4@gateway/web/freenode/ip.219.91.250.164) has joined #beagle
  • [19:08:26] * gusnan (~gusnan@unaffiliated/gusnan) Quit (Ping timeout: 240 seconds)
  • [19:10:40] * gusnan (~gusnan@unaffiliated/gusnan) has joined #beagle
  • [19:12:46] * NishanthMenon (nmenon@nat/ti/x-hlekuvwlnguxzfsm) has joined #beagle
  • [19:16:21] <rkc> yeah... that looks to be the case
  • [19:17:08] <rkc> any idea how to build just the kernel and not all the modules
  • [19:17:36] <rkc> I make a samll change in TI BSP and it goes on to build whole set of modules
  • [19:17:45] <rkc> which I anyway do not use
  • [19:25:19] <veremit> 'make' should only rebuild what is necessarry.. if you're using a script you will have to dig deeper into it
  • [19:25:34] * RoyBellingan (~roy@195.189.129.21) Quit (Quit: Konversation terminated!)
  • [19:35:32] * zacdev (~zacdev@unaffiliated/zacdev) has joined #beagle
  • [19:35:32] * zacdev (~zacdev@unaffiliated/zacdev) has joined #beaglebone
  • [19:40:00] * zacdev (~zacdev@unaffiliated/zacdev) Quit (Max SendQ exceeded)
  • [19:43:10] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) has joined #beagle
  • [19:43:50] * alexanderhiam (~alexander@216.151.180.84) Quit (Ping timeout: 244 seconds)
  • [19:47:31] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) Quit (Ping timeout: 246 seconds)
  • [19:49:08] * darkfader (~darkfader@2001:610:600:896d:d5ed:cc82:9c47:85c5) has joined #beagle
  • [19:52:45] * skhreze_ (~debian@ip-5-172-247-226.free.aero2.net.pl) Quit (Ping timeout: 252 seconds)
  • [19:53:35] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) has joined #beagle
  • [19:56:02] * j0rd__ (~j0rd_@unaffiliated/j0rd-/x-9112651) Quit (Read error: Connection reset by peer)
  • [19:56:46] * skhreze (~debian@ip-5-172-247-199.free.aero2.net.pl) has joined #beagle
  • [19:57:24] * nerienna (~nerienna@p5491F01F.dip0.t-ipconnect.de) Quit (Remote host closed the connection)
  • [19:58:46] * WillAmes (~py@ool-1826eaa1.dyn.optonline.net) Quit (Remote host closed the connection)
  • [20:00:39] * rkc (6a331899@gateway/web/freenode/ip.106.51.24.153) Quit (Ping timeout: 246 seconds)
  • [20:01:02] * WillAmes (~py@ool-1826eaa1.dyn.optonline.net) has joined #beagle
  • [20:07:30] * jmesmon (~ydoc@vcr.einic.org) Quit (Ping timeout: 260 seconds)
  • [20:08:57] * bengo (~textual@12.184.218.25) has joined #beagle
  • [20:12:07] * bengo (~textual@12.184.218.25) Quit (Max SendQ exceeded)
  • [20:12:42] * bengo (~textual@12.184.218.25) has joined #beagle
  • [20:15:21] <zmatt> veremit: using ttyO0 is safer however, since it'll merely emit a warning when used with the 8250 driver, while using ttyS0 with the omap-serial driver will not work
  • [20:26:12] * vmayoral (~vmayoral@79.150.62.208) has joined #beagle
  • [20:27:11] <veremit> who still uses the omap driver, anyways!? :D
  • [20:27:28] <veremit> ohai zmatt ...
  • [20:28:10] <veremit> I s'pose if its a TI kernel ...
  • [20:30:45] * vmayoral (~vmayoral@79.150.62.208) Quit (Ping timeout: 250 seconds)
  • [20:32:53] <zmatt> I still don't understand why we're moving to another driver at all
  • [20:34:28] * jmesmon (~jmesmon@vcr.einic.org) has joined #beagle
  • [20:35:11] <veremit> -shrug- integration and simplification is good?
  • [20:36:04] <veremit> maybe arm should give linus the two-fingers and fork off .. we can have thousands of variants then ... ;)
  • [20:36:06] <zmatt> lol, simplification... add even more special-cases to a driver that it's already such a mess that no sane person would touch it with a ten foot pole
  • [20:36:39] <zmatt> given that any improvement on your target might break stuff for one of the numerous other incompatible variants of the peripheral
  • [20:36:39] <veremit> eh, its still one driver .. who cares that its a load of spaghetti ?!
  • [20:37:35] <zmatt> I do, I regard the backward compat (strong emphasis on "backward") with 8250 to be a relic that should be killed in its sleep rather than cherished
  • [20:37:57] <zmatt> it's a horrible interface
  • [20:38:23] <veremit> some would argue .. why are we still using serial?
  • [20:38:37] <veremit> but then you can just look at musb in the am335x .. and that sends ME running ...
  • [20:38:50] <zmatt> because it works fine for many applications
  • [20:39:01] <veremit> right
  • [20:39:39] <zmatt> and it's highly ubiquitous
  • [20:40:03] <veremit> indeed
  • [20:40:43] <zmatt> which is why I'd much rather would have had a *good* peripheral interface rather than that horrid crap from the 80s or whenever this cruft clawed its way into this world
  • [20:40:57] <veremit> surely then, you'd expect it was possible to make some form of 'unified' interface to it .. rather than a per-device implementation?!
  • [20:41:51] <zmatt> sure, if all vendors suddenly decided to cooperate for the same of allowing code to be ported from their devices to that of their competitors :P
  • [20:41:56] <zmatt> *for the sake
  • [20:42:22] <zmatt> in practice I'd rather have the chip I'm working with have an actual *good* interface
  • [20:42:49] <zmatt> note that this doesn't preclude a backwards compatible interface being present also... but I wouldn't touch that part
  • [20:43:07] <veremit> lol
  • [20:43:18] <veremit> nuff said I think :)
  • [20:43:49] * daemoneye (daemoneye@unaffiliated/daemoneye) Quit (Quit: So long and thanks for all the fish)
  • [20:44:31] <zmatt> yeah, there are downsides also to writing a driver for the omap-serial peripheral specifically... mine turned out to be *too efficient*
  • [20:45:02] <zmatt> for some reason the uarts on am335x can't handle more than about 8-10 bytes written consecutively, even if there's plenty of fifo space
  • [20:45:20] <zmatt> I need to insert dummy writes to slow down the rate
  • [20:45:22] <zmatt> :P
  • [20:46:07] <zmatt> I guess other drivers are already too inefficient to trigger the problem
  • [20:46:24] <veremit> that's pathetic
  • [20:46:37] <veremit> its .. unusable
  • [20:46:39] <zmatt> probably a clock domain crossing issue of sorts
  • [20:46:59] <veremit> more crappy dma issues?
  • [20:47:06] <zmatt> actually it's easy to work around, just write some harmless register in between two byte writes
  • [20:47:15] <zmatt> no actually I think using dma would also fix the problem
  • [20:47:19] <zmatt> haven't tested that yet
  • [20:47:45] <veremit> so writing to the fifo buffer .. what happens? it drops bytes or blocks or what?
  • [20:47:59] <veremit> why have a fifo?!
  • [20:48:06] * veremit head-desks
  • [20:48:13] * berton (~fabio@201.22.227.56) Quit (Quit: Leaving)
  • [20:48:19] <zmatt> an edma TC can't have more than 4 writes outstanding, and since the uart doesn't allow any efficient mechanism to write data into its fifo, the dma controller has no option but to use single writes for each byte
  • [20:49:15] <veremit> ok what about "inefficient means" ..
  • [20:49:46] <veremit> I'ma stick to microcontrollers lol .. writing assembly fifo's seems somehow 'more' efficient ..
  • [20:49:47] <zmatt> it seems to muck up pointers or counters... results in the last byte written being repeated many times (I think 64 minus the number of bytes written since the overflow, or somerhing like that)
  • [20:50:05] <zmatt> you don't want single-byte transfers
  • [20:50:21] <veremit> well not single -byte writes no...
  • [20:50:45] <veremit> but wtf. why is there a fifo if you can't write to it .. and wtf doesn't dma work ..
  • [20:50:52] <zmatt> dma works fine
  • [20:50:52] <veremit> its like the device is a bit of swiss cheese!
  • [20:51:18] <veremit> well .. let me rephrase .. it IS A bit of swiss cheese . just a few bits of it work "well enough" lol
  • [20:51:29] <zmatt> but the 8250 interface only has a single-byte data-write register
  • [20:51:44] <zmatt> there's no way to write more than one byte to it in a single transfer
  • [20:51:46] <veremit> Really?!
  • [20:52:12] <veremit> there's no multi-byte interface .. ?
  • [20:52:15] <zmatt> no
  • [20:52:30] <veremit> like .. you're never gonna need more than 640k of ram .. you won't ever write more than 1 byte on serial!?
  • [20:52:32] <zmatt> hello? this interface probably dates back to 8-bit microcontrollers :P
  • [20:52:36] * Shadyman (~matthew@unaffiliated/shadyman) has joined #beagle
  • [20:52:51] <veremit> what crack-head came up with that idea?
  • [20:52:57] * veremit mutters
  • [20:53:18] <zmatt> you think this is bad? hahahahaha
  • [20:53:31] * Yotson (~Yotson@2001:980:6ac8:1:109d:328d:c5d5:d68c) Quit (Quit: .)
  • [20:53:33] <zmatt> this is a minor inconvenience compared to the horrors of the 8250 interface
  • [20:53:49] <veremit> well .. I should know better than to scratch the surface of linux drivers ...
  • [20:54:18] <veremit> where I have, on good authority, tis written "don't fuck with this, t works...."
  • [20:54:22] <zmatt> well the linux driver is even worse since it attempts to support many uarts with roughly-but-not-really-quite-compatible register interfaces
  • [20:55:01] <veremit> that is invariably going to be a fudge when you work with a number of different implementations of varying 'compliance' ..
  • [20:55:19] <zmatt> veremit: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/379360/1342615#1342615
  • [20:59:04] * skhreze_ (~debian@ip-5-172-247-233.free.aero2.net.pl) has joined #beagle
  • [20:59:23] <zmatt> veremit: I nowadays take the short route "reset" -> all the way to the bottomleft, do config there, move to "operational / fifo config" and stay there
  • [20:59:45] <veremit> wow that looks ... horrible ..
  • [21:00:25] * cybernaut hands out the clubs to allow people to "reset" their hardware "appropriately"
  • [21:00:31] * bengo (~textual@12.184.218.25) Quit (Quit: My Mac has gone to sleep. ZZZzzz…)
  • [21:00:56] * veremit accepts gladly
  • [21:00:58] * skhreze (~debian@ip-5-172-247-199.free.aero2.net.pl) Quit (Ping timeout: 250 seconds)
  • [21:01:06] <zmatt> if there's any need to move back to config mode (any flavor), just reset the uart and perform the same procedure again... keeps things simple
  • [21:01:11] <zmatt> ... ish
  • [21:01:42] <cybernaut> veremit hit the hardware engineer first it will make you feel better ;)
  • [21:01:48] <zmatt> note that "reconfiguring" includes things like enabling/disabling hardware or software flow control
  • [21:01:57] <veremit> cybernaut .. methinks bashing self is not recommended ..
  • [21:02:12] <zmatt> since you can't access that register unless in the bottomleft circle
  • [21:02:24] <zmatt> but doing so kills the uart clock and corrupts any character in transit
  • [21:02:42] <veremit> sounds altogether overcomplicated to me ..
  • [21:02:45] <zmatt> hence you may as well just reset the thing
  • [21:03:01] <zmatt> the interfaces is highly modal
  • [21:03:18] <zmatt> to the point that navigating it becomes sort of a puzzle-adventure game :P
  • [21:03:29] <veremit> except .. not a fun one ..
  • [21:03:50] <zmatt> correct
  • [21:03:57] <zmatt> the irq structure is equally horrid
  • [21:05:17] <cybernaut> a lot of that may be legacy IP they decided to recycle from former years of brilliant planning.
  • [21:05:35] * NulL`` (~bleh1@80.65.242.82) Quit (Ping timeout: 264 seconds)
  • [21:05:46] <zmatt> and there's really no excuse... I refuse to believe that allowing direct access to the registers (at different addresses) would be problematic
  • [21:06:23] <zmatt> note also that the uart doesn't put an id/version register at the start of its address space like nearly every other peripheral does
  • [21:06:45] <zmatt> instead its fifo read/write register is there
  • [21:06:48] <cybernaut> it's probably not an arm peripheral
  • [21:06:55] <zmatt> none of these are ARM peripherals
  • [21:07:07] <cybernaut> I would say there is the first mistake.
  • [21:07:12] <zmatt> the uart has plenty of TI in the mix though
  • [21:07:41] <zmatt> but mostly just adding stuff, not any kind of cleanup or refactoring
  • [21:07:54] <zmatt> it's still the same ancient uart interface
  • [21:07:57] <cybernaut> the whole reason to use ARM peripherals is because they are almost standardized (IE easy to work with and configure based on existing libraries)
  • [21:08:06] <zmatt> complete with support for 5 data bits and 1.5 stop bit
  • [21:08:17] <zmatt> in case you need to interface with a 45 baud teletype
  • [21:08:18] <zmatt> :P
  • [21:08:55] <cybernaut> no 110 or was that 50.. can't remember in EBDIC encoding or whatever it was.
  • [21:09:06] <zmatt> cybernaut: I don't have much experience with ARM peripherals, but I've seen ARM make plenty of bad choices in peripheral design
  • [21:09:09] <zmatt> baudot
  • [21:09:48] * jpirko (~jirka@jirka.pirko.cz) Quit (Quit: Leaving)
  • [21:10:10] <cybernaut> that was designed for a mechanical switch system to select the character to print out. It was all mechanical in that day and age.
  • [21:10:59] <veremit> you're gonna tell me, that we still have to interface to mechanical computers? in the 21st century?
  • [21:11:10] <veremit> somebody PLEASE extinguish that crack=pipe lol
  • [21:11:54] <zmatt> cybernaut: for example you can't inspect the configuration of the system timer on the Cortex-M3 without also reading the event-bit which is set when the timer hits zero
  • [21:11:57] <cybernaut> zmatt I don't disagree but reinventing stupid with weird interfaces for a PC on an ARM machine doesn't make sense. Yes they were smokin' but to quote a baseball player "in one word 'you-never-know'"
  • [21:12:22] <zmatt> cybernaut: and that bit clears on read
  • [21:13:14] <veremit> zmatt.. why does that matter?
  • [21:13:20] <zmatt> which means that if you want to check the system timer config, if you wanted to do anything with the event bit you're forced to do it right there and then even if that makes no sense in your code flow, since it's been cleared by the read
  • [21:13:47] <zmatt> (in general, "clear on read" registers DIE DIE DIE)
  • [21:14:04] <veremit> flags are often 'clear on read'
  • [21:14:12] <zmatt> almost never luckily in modern peripherals
  • [21:14:18] <veremit> that a common hardware occurance
  • [21:14:22] <zmatt> used to be
  • [21:14:29] <zmatt> in microcontrollers still is probably
  • [21:14:37] * bkearns (~bkearns@216-75-239-130.static.wiline.com) Quit (Quit: Leaving.)
  • [21:14:42] <veremit> although explicitly writing a 0 has some merit .. I think clear-on-read is simpler
  • [21:15:06] <zmatt> veremit: except when that bit is packed together with non-status-bits in one register
  • [21:15:22] <zmatt> or if you need different status info at different locations in your code
  • [21:15:25] <veremit> well thats just poor design :) or implementation...
  • [21:15:33] <zmatt> my point exactly
  • [21:15:46] * vagrantc (~vagrant@unaffiliated/vagrantc) Quit (Quit: leaving)
  • [21:15:56] <veremit> I don't imagine you're short on address space in this age ..
  • [21:16:12] <veremit> I've seen plenty of registers with 'unused' bits and addresses
  • [21:16:14] <zmatt> clear on read also sucks for debugging, though if you're lucky the peripheral doesn't clear if the read is by the debugger (if it can notice that)
  • [21:16:30] <cybernaut> zmatt a tale of TI, they did the same thing with the msp430 SPI serial controller it can be a pain too. Essentially you can get an overflow condition if you don't read the receive register when using DMA with the output buffer. You have to read the read register each DMA cycle therefore. Furthermore you can received SPI DMA without writing SPI data with DMA so you have to do weird things to use DMA on the processor. Oh did I mention
  • [21:16:30] <cybernaut> that the registers although 8bit have to be accessed as 16bit or you reads and writes get messed up?
  • [21:16:33] <veremit> how would it1?
  • [21:16:45] <zmatt> veremit: metadata bit in the request
  • [21:17:10] <veremit> cybernaut: lol
  • [21:17:21] <veremit> zmatt: designed??!!!!
  • [21:17:34] <zmatt> veremit: yes, MReqDebug in OCP-terminology
  • [21:17:52] * vagrantc (~vagrant@unaffiliated/vagrantc) has joined #beagle
  • [21:18:00] <veremit> sucj inconsistency, much confusion.
  • [21:18:02] <zmatt> you can also configure the on-chip firewalls to allow or deny access based on it
  • [21:18:18] <cybernaut> zmatt yeah I know that problem it happens in the MSP430 when debugging when you want to know the state of something it's automatically cleared and your program can't work correctly.
  • [21:18:20] <veremit> vrey headache lol
  • [21:18:45] <zmatt> veremit: but actually I consider it a good thing is debugger-reads never alter the peripheral state
  • [21:18:50] * penth (~rachel@c-68-81-92-61.hsd1.pa.comcast.net) Quit (Remote host closed the connection)
  • [21:18:54] <zmatt> so you can actually safely dump registers
  • [21:19:11] <zmatt> too bad it's not actually consistently implemented in peripherals
  • [21:19:12] <veremit> zmatt: well that could really cock things up, so it is desireable...
  • [21:20:03] <cybernaut> does TI disable DMA when the debugger is active on the AM35XX?
  • [21:20:35] <zmatt> DMA itself? no. many peripherals have a suspend-signal though, with varying effects
  • [21:20:56] <zmatt> and it's programmable which core's debug-suspend they react to
  • [21:21:27] <zmatt> so e.g. you could have a timer used by PRU freeze while the PRU is halted in debug
  • [21:21:41] <cybernaut> well on one of their parts they disable DMA completely so you can't debug DMA code without poke and hope. It's hard to see what the behavior is and their documentation is abysmal on DMA often.
  • [21:22:20] <zmatt> cybernaut: DMA stays fully operational, though of course a suspended peripheral will probably cease to generate new DMA requests
  • [21:22:44] <zmatt> with DMA I mean EDMA in this case of course
  • [21:23:44] <zmatt> debug suspend will halt integrated DMA that some peripherals/subsystems have of course (if they support debug suspend), although that never affects the ability to inspect
  • [21:25:07] <zmatt> veremit: I also think clear-on-read made more sense on microcontrollers which generally had simpler overall logic, and doing an additional write was an unnecessary expense
  • [21:25:22] <zmatt> on a SoC like the AM335x the write is pretty much free, especially compared to the read
  • [21:25:26] * alexanderhiam (~alexander@c-24-147-39-76.hsd1.nh.comcast.net) has joined #beagle
  • [21:26:13] <veremit> zmatt.. its a fair point, but depends where the logic is coming from... where TI is concerned .. who knows!
  • [21:26:15] <zmatt> (since the write just goes into a queue, while for a read the cpu really needs to sit and wait a full ping-time to the peripheral)
  • [21:26:35] * skhreze_ (~debian@ip-5-172-247-233.free.aero2.net.pl) Quit (Ping timeout: 240 seconds)
  • [21:26:53] <zmatt> yeah, most recent or semi-recent TI peripherals have abandoned clear-on-read registers
  • [21:28:21] <cybernaut> zmatt that is because of bugs in compilers where the volatile keyword wasn't adhered too by the code generator. It created a lot of bugs in software that 'certain' companies blamed on the programmers but where the compilers fault.
  • [21:28:34] <zmatt> don't get me started
  • [21:28:49] <zmatt> C/C++ is really horrible for dealing with memory-mapped I/O
  • [21:28:51] * cybernaut grins.
  • [21:28:57] <zmatt> which quite sucks, since there isn't really a better alternative
  • [21:29:45] <zmatt> I would really appreciate being able to slap attributes onto things to explain to the compiler what the constraints and semantics are
  • [21:29:55] <cybernaut> that's why they introduced the volatile keyword but MS and intel compilers and "certain" others optimized proper reads and writes out as 'redundant'.
  • [21:30:08] <zmatt> volatile is a very blunt instrument
  • [21:30:16] <zmatt> I often don't want to make stuff volatile
  • [21:30:40] <cybernaut> for HW registers that's a must unfortunately.
  • [21:30:56] <zmatt> actually most registers of many TI peripherals can be treated like memory
  • [21:31:17] <zmatt> with an occasional compiler barrier where necessary to enforce ordering
  • [21:31:40] <zmatt> there are a few really obnoxious ones though
  • [21:31:57] <zmatt> like some ARM peripheral supports 8-bit and 32-bit access, but not 16-bit access
  • [21:31:58] * eFfeM (~frans@c73189.upc-c.chello.nl) Quit (Quit: Leaving.)
  • [21:32:30] <cybernaut> Heh or some peripherals "allow" 8bit access but not really ;)
  • [21:32:39] <zmatt> without volatile, evaluating (foo.x & 0xffff) gets optimized to a 16-bit access if you don't slap on a "volatile"
  • [21:32:46] * VirG1 (~VirGin@c-73-25-235-187.hsd1.or.comcast.net) has joined #beagle
  • [21:32:55] <zmatt> but volatile often triggers many unnecessary accesses
  • [21:33:06] * VirG (~VirGin@c-73-25-235-187.hsd1.or.comcast.net) Quit (Ping timeout: 272 seconds)
  • [21:33:29] <zmatt> and the ping time to a typical peripheral on the am335x is about 150 clock cycles iirc
  • [21:34:33] * nashpa (~nashpa@dliviu.plus.com) Quit (Quit: Going away)
  • [21:34:33] <zmatt> I'd much prefer to be able to tell the compiler "hey, this is pretty much memory-ish, but just don't use 16-bit access, okay?"
  • [21:35:34] * j0rd__ (~j0rd_@unaffiliated/j0rd-/x-9112651) has joined #beagle
  • [21:35:52] * nashpa (~nashpa@dliviu.plus.com) has joined #beagle
  • [21:36:46] <cybernaut> hmmm you can't define it as "volatile uint8_t this_reg;" and "#pragma LOCATE(this_reg, XYZ)" ?
  • [21:38:13] <zmatt> the point is that the registers 32-bit and not uncommonly actually contain 16-bit fields, i.e. when modeling the peripheral as a structure I'd normally use want to use u16
  • [21:38:20] <zmatt> except I can't
  • [21:39:26] <zmatt> and as I said, I actually normally avoid unnecessary use of volatile... this sort of peripheral behaviour unfortunately doesn't leave any choice currently
  • [21:40:22] <zmatt> but volatile is the other extreme... it takes every ability to optimize away from the compiler
  • [21:40:58] <cybernaut> indeed it's hard to avoid because the back end optimizer doesn't know anything and could switch access to 16bit or 32bit or 8bit. The optimizer is completely ignorant of how the peripheral is used is a reality.
  • [21:41:01] * [Butch] (~butch@169.145.89.207) has joined #beagle
  • [21:41:10] <zmatt> while most of the time I deal with almost-but-not-quite-memory where most optimizations would still be valid. But I hvae no way to explain this to the compiler
  • [21:41:31] <zmatt> like I said, I really wish for some attributes for that
  • [21:41:46] <zmatt> or a better language
  • [21:42:40] <zmatt> since C/C++ seem to be getting more obnoxious to use for systems programming all the time
  • [21:43:07] * pmezydlo (5947b13d@gateway/web/freenode/ip.89.71.177.61) has joined #beagle
  • [21:43:25] <zmatt> the only good move in C++ lately has been better metaprogramming support (although still mediocre)
  • [21:43:47] <cybernaut> optimizers make choices that are based on patterns of register and memory access use. unfortunately this is not always valid with peripheral usage.
  • [21:44:08] <zmatt> that's what attributes are for
  • [21:45:06] <zmatt> if they can make crazy shit like [[carries_dependency]], they could also add some attributes to model the constraints of memory-mapped I/O :P
  • [21:45:26] <zmatt> afk for a bit
  • [21:45:35] * alexanderhiam (~alexander@c-24-147-39-76.hsd1.nh.comcast.net) Quit (Ping timeout: 240 seconds)
  • [21:45:56] <cybernaut> I believe that is what the #pragma operator in the precompiler was designed to do however ... it's compiler specific.
  • [21:50:26] * Vasco is now known as Vasco_O
  • [21:52:56] * pmezydlo (5947b13d@gateway/web/freenode/ip.89.71.177.61) Quit (Quit: Page closed)
  • [21:53:43] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) Quit (Remote host closed the connection)
  • [21:53:47] * rob_w (~rob@unaffiliated/rob-w/x-1112029) Quit (Read error: Connection reset by peer)
  • [22:03:55] * named (~unknown@5.148.129.203) Quit (Ping timeout: 240 seconds)
  • [22:04:28] * roric (~roric@h196n19-vrr-a31.ias.bredband.telia.com) has joined #beagleboard
  • [22:04:28] * roric (~roric@h196n19-vrr-a31.ias.bredband.telia.com) has joined #beaglebone
  • [22:13:45] * kiwichris (~kiwichris@CPE-60-225-146-35.hhui6.ken.bigpond.net.au) Quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
  • [22:15:03] * vmayoral (~vmayoral@208.Red-79-150-62.dynamicIP.rima-tde.net) has joined #beagle
  • [22:16:20] * arianepaola (~ariane@unaffiliated/arianepaola) Quit (Read error: Connection reset by peer)
  • [22:19:26] * vmayoral (~vmayoral@208.Red-79-150-62.dynamicIP.rima-tde.net) Quit (Ping timeout: 240 seconds)
  • [22:19:56] * named (~unknown@5.148.129.203) has joined #beagle
  • [22:20:33] * arianepaola (~ariane@unaffiliated/arianepaola) has joined #beagle
  • [22:22:20] * Yogesh (db5bfaa4@gateway/web/freenode/ip.219.91.250.164) Quit (Quit: Page closed)
  • [22:32:00] * named (~unknown@5.148.129.203) Quit (Ping timeout: 272 seconds)
  • [22:32:56] * kiwichris (~kiwichris@msc1401703.lnk.telstra.net) has joined #beagle
  • [22:39:11] * NishanthMenon (nmenon@nat/ti/x-hlekuvwlnguxzfsm) Quit (Quit: Trying to have as good a life as I can under the circumstances.)
  • [22:40:18] * Ceriand|desktop (~Ceriand@unaffiliated/ceriand) has joined #beagle
  • [22:41:10] * Elray (~ray@cpe90-146-154-139.liwest.at) has joined #beagle
  • [22:42:23] <Elray> i guys i'm havin some problem to update the kernel of my BBB
  • [22:42:48] <Elray> when i try to run it at the end he give me this error
  • [22:42:58] <Elray> Resolving rcn-ee.net (rcn-ee.net)... 64.111.100.114
  • [22:42:58] <Elray> Connecting to rcn-ee.net (rcn-ee.net)|64.111.100.114|:443... connected.
  • [22:42:58] <Elray> ERROR: The certificate of `rcn-ee.net' is not trusted.
  • [22:42:58] <Elray> ERROR: The certificate of `rcn-ee.net' hasn't got a known issuer.
  • [22:43:18] <Elray> i have already update the date at today
  • [22:43:40] <Elray> any tips for solve it?
  • [22:44:06] * named (~unknown@5.148.129.203) has joined #beagle
  • [22:47:56] <froggytold> hmm Elray that rings a bell
  • [22:48:26] <Elray> a good bell or a bad one?
  • [22:48:43] <froggytold> something to todo with curl
  • [22:50:30] <froggytold> check out derek molloy
  • [22:50:34] <froggytold> http://derekmolloy.ie/fixing-git-and-curl-certificates-problem-on-beaglebone-blac/
  • [22:50:53] <froggytold> yah the date is good to check..
  • [22:52:45] <froggytold> [C[1;3C/win 32
  • [22:52:50] * Elray (~ray@cpe90-146-154-139.liwest.at) Quit (Ping timeout: 260 seconds)
  • [22:53:45] * Zephyr1138 (~wasinger@75-166-176-169.hlrn.qwest.net) has left #beaglebone
  • [22:53:50] * ohama (ohama@cicolina.org) Quit (Ping timeout: 240 seconds)
  • [22:53:57] * Elray (~ray@cpe90-146-154-139.liwest.at) has joined #beagle
  • [22:55:31] * ohama (ohama@cicolina.org) has joined #beaglebone
  • [22:57:08] <Elray> ah cool i solved doing git pull
  • [22:57:19] <Elray> in cd /opt/scripts/tools
  • [23:01:01] * bfederau (~quassel@service.basyskom.com) Quit (Remote host closed the connection)
  • [23:01:13] * bfederau (~quassel@service.basyskom.com) has joined #beagle
  • [23:10:12] * j0rd__ (~j0rd_@unaffiliated/j0rd-/x-9112651) Quit (Read error: Connection reset by peer)
  • [23:10:47] * kevinsan (~kevinsan@takahe.susa.net) has left #beagle
  • [23:10:59] * dwery (~dwery@nslu2-linux/dwery) Quit (Ping timeout: 264 seconds)
  • [23:19:11] * Elray (~ray@cpe90-146-154-139.liwest.at) has left #beagle
  • [23:25:24] * tomeff (~tomeff@ip-78-102-111-158.net.upcbroadband.cz) Quit (Quit: tomeff)
  • [23:29:05] * j0rd__ (~j0rd_@unaffiliated/j0rd-/x-9112651) has joined #beagle
  • [23:34:54] * CrypticGator (~CrypticGa@99-45-218-113.lightspeed.miamfl.sbcglobal.net) has joined #beagle
  • [23:36:32] * Set_ (~Set_@ip70-189-47-143.lf.br.cox.net) has joined #beagle
  • [23:46:57] * jacob_ (c73b6a3a@gateway/web/freenode/ip.199.59.106.58) has joined #beagle
  • [23:48:21] * j0rd__ (~j0rd_@unaffiliated/j0rd-/x-9112651) Quit (Read error: Connection reset by peer)
  • [23:49:30] * j0rd__ (~j0rd_@unaffiliated/j0rd-/x-9112651) has joined #beagle
  • [23:51:02] * jamesaxl (~jamesaxl@adsl196-168-23-217-196.adsl196-9.iam.net.ma) Quit (Ping timeout: 276 seconds)
  • [23:53:24] * jacob_ (c73b6a3a@gateway/web/freenode/ip.199.59.106.58) Quit (Ping timeout: 246 seconds)
  • [23:54:11] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) has joined #beagle
  • [23:54:14] * [Butch] (~butch@169.145.89.207) Quit (Quit: I'm out . . .)
  • [23:56:31] * florian (~fuchs@Maemo/community/contributor/florian) Quit (Quit: Verlassend)
  • [23:57:35] * tchan (~tchan@lunar-linux/developer/tchan) Quit (Quit: WeeChat 1.2)
  • [23:58:49] * Nico44 (~Nico44@crb44-1-82-67-127-241.fbx.proxad.net) Quit (Ping timeout: 246 seconds)
  • [23:59:34] * named (~unknown@5.148.129.203) Quit (Ping timeout: 260 seconds)