• [00:01:05] * NishanthMenon (~nmenon@192.94.92.14) Quit (Quit: EOF)
  • [00:04:45] * cjoe (~customerj@fibhost-66-7-177.fibernet.hu) Quit (Ping timeout: 260 seconds)
  • [00:21:31] <jkridner> koen: g_multi "just works" with a Windows host.
  • [00:21:40] <jkridner> so, seems like it is a Mac issue.
  • [00:25:17] <mranostay> jkridner: take that back!
  • [00:25:56] <mranostay> alan_o: http://26-26-54.hardwarebug.org/139
  • [00:28:39] <xanium4332> can someone explain what device tree phandles are?
  • [00:28:46] <xanium4332> and how fragments work?
  • [00:28:54] * dj_pi (~asd@c-107-5-25-243.hsd1.mi.comcast.net) has joined #beagle
  • [00:35:06] <CareBear\> xanium4332 : why are you asking about this in #beagle?
  • [00:35:41] <CareBear\> xanium4332 : that makes no sense whatsoever. why don't you find the correct forum for your questions? that way you may actually be able to get answers, instead of getting mocked and laughed at.
  • [00:36:59] * thurbad (~natesewel@cpe-70-113-204-247.austin.res.rr.com) has joined #beagle
  • [00:38:52] * davest (Adium@nat/intel/x-xhnhvozaxmibrlwn) Quit (Quit: Leaving.)
  • [00:42:21] <xanium4332> only because the people who are writing the device tree files for capes are here. They seem to have a clear understanding of fragment usage (because they are used in the cape dt files)
  • [00:42:54] <mrpackethead_> the hobbit is happy
  • [00:42:55] <mrpackethead_> :-)
  • [00:43:05] <xanium4332> and the previous discussion about phandles I read online was concerning capes
  • [00:43:44] <mrpackethead_> its not normally that exciting to see 50% duty cycle square waves on the scope
  • [00:43:46] <mrpackethead_> but it is today
  • [00:44:03] <mrpackethead_> mranostay: thanks for the pointers
  • [00:51:17] * modmaker (~ncbas@63-11.bbned.dsl.internl.net) Quit (Ping timeout: 252 seconds)
  • [00:59:14] * cjoe (~customerj@fibhost-66-7-177.fibernet.hu) has joined #beagle
  • [00:59:15] * cjoe (~customerj@fibhost-66-7-177.fibernet.hu) has joined #beagleboard
  • [00:59:15] * cjoe (~customerj@fibhost-66-7-177.fibernet.hu) has joined #beaglebone
  • [01:05:25] * contempt (contempt@unaffiliated/contempt) Quit (Ping timeout: 260 seconds)
  • [01:10:41] * KeatonT (~textual@unaffiliated/keatont) has joined #beagle
  • [01:13:06] * ka6sox is now known as ka6sox-away
  • [01:13:40] * contempt (contempt@unaffiliated/contempt) has joined #beagleboard
  • [01:13:41] * contempt (contempt@unaffiliated/contempt) has joined #beagle
  • [01:15:56] * djerome (~djerome@ip68-2-20-108.ph.ph.cox.net) has joined #beaglebone
  • [01:17:54] * bbm (181fe126@gateway/web/freenode/ip.24.31.225.38) has joined #beagle
  • [01:19:22] * bbm1 (~Thunderbi@24.31.225.38) has joined #beagle
  • [01:22:08] * bbm (181fe126@gateway/web/freenode/ip.24.31.225.38) Quit (Ping timeout: 245 seconds)
  • [01:22:32] * bbm1 (~Thunderbi@24.31.225.38) Quit (Client Quit)
  • [01:23:48] <mrpackethead_> it is deathly silent.
  • [01:34:38] * XorA is now known as XorA|gone
  • [01:47:05] * smplman (~speery@cn-sfo1-natout.cnet.com) Quit (Quit: smplman)
  • [02:01:52] * DJWillis (~djwillis@cpc1-bath5-2-0-cust122.aztw.cable.virginmedia.com) has joined #beagle
  • [02:04:03] * DJW|Home (~djwillis@cpc1-bath5-2-0-cust122.aztw.cable.virginmedia.com) Quit (Ping timeout: 244 seconds)
  • [02:04:39] * voltin (321b1975@gateway/web/freenode/ip.50.27.25.117) has joined #beagle
  • [02:05:18] * mranostay screams and stabs mrpackethead_
  • [02:05:43] <mrpackethead_> mranostay: but your attempt was in vain.. I have the ring on
  • [02:05:45] <mrpackethead_> you missed
  • [02:07:28] <mrpackethead_> https://fbcdn-sphotos-a-a.akamaihd.net/hphotos-ak-snc7/295453_10151373113247661_1751171758_n.jpg
  • [02:07:35] <mrpackethead_> i got my PWM
  • [02:07:36] <mrpackethead_> :-)
  • [02:07:48] * edahling (~edahling@wbc.res.wpi.net) Quit (Quit: Leaving)
  • [02:12:19] * ka6sox-away is now known as ka6sox
  • [02:14:41] * KeatonT (~textual@unaffiliated/keatont) Quit (Quit: Textual IRC Client: http://www.textualapp.com/)
  • [02:14:42] * kiilo (~kiilo@46-126-77-178.dynamic.hispeed.ch) Quit (Read error: Connection reset by peer)
  • [02:15:22] * xanium4332 (~xanium433@2001:470:1f09:10:225:90ff:fea2:995f) Quit (Quit: WeeChat 0.4.0)
  • [02:16:58] * emeb (~ericb@ip72-201-78-226.ph.ph.cox.net) Quit (Quit: Leaving.)
  • [02:17:46] * kiilo (~kiilo@46-126-77-178.dynamic.hispeed.ch) has joined #beagle
  • [02:17:48] * kiilo (~kiilo@46-126-77-178.dynamic.hispeed.ch) Quit (Remote host closed the connection)
  • [02:18:03] * kiilo (~kiilo@46-126-77-178.dynamic.hispeed.ch) has joined #beagle
  • [02:18:04] * emeb (~ericb@ip72-201-78-226.ph.ph.cox.net) has joined #beagle
  • [02:18:58] * kiilo (~kiilo@46-126-77-178.dynamic.hispeed.ch) Quit (Read error: Connection reset by peer)
  • [02:22:17] * kiilo (~kiilo@46-126-77-178.dynamic.hispeed.ch) has joined #beagle
  • [02:29:13] * kiilo (~kiilo@46-126-77-178.dynamic.hispeed.ch) Quit (Read error: Connection reset by peer)
  • [02:31:08] * slchen (~slchen@123-195-161-155.dynamic.kbronet.com.tw) has joined #beagle
  • [02:31:43] * voltin (321b1975@gateway/web/freenode/ip.50.27.25.117) Quit (Ping timeout: 245 seconds)
  • [02:33:51] * nullpuppy (~dustin@freematrix/staff/nullpuppy) Quit (Quit: new UPS ... :D)
  • [02:41:15] * emeb (~ericb@ip72-201-78-226.ph.ph.cox.net) Quit (Quit: Leaving.)
  • [02:42:03] * emeb (~ericb@ip72-201-78-226.ph.ph.cox.net) has joined #beagle
  • [02:47:11] * contempt (contempt@unaffiliated/contempt) Quit (Ping timeout: 255 seconds)
  • [02:52:06] * Ceriand|desktop (~Ceriand@unaffiliated/ceriand) has joined #beagle
  • [02:55:26] * nullpuppy (~dustin@freematrix/staff/nullpuppy) has joined #beagle
  • [02:57:56] * djerome (~djerome@ip68-2-20-108.ph.ph.cox.net) Quit (Remote host closed the connection)
  • [03:01:49] * bzb (~bzb@69-196-189-45.dsl.teksavvy.com) has joined #beagle
  • [03:23:06] * contempt (contempt@unaffiliated/contempt) has joined #beagleboard
  • [03:23:06] * contempt (contempt@unaffiliated/contempt) has joined #beagle
  • [03:31:25] * slchen (~slchen@123-195-161-155.dynamic.kbronet.com.tw) Quit (Quit: slchen)
  • [03:38:24] * harshpb (~harshpb@122.167.242.222) has joined #beagleboard
  • [03:46:04] * jkridner (~jason@pdpc/supporter/active/jkridner) Quit (Quit: jkridner)
  • [03:52:06] * jkridner_ (~jason@pdpc/supporter/active/jkridner) has joined #beagle
  • [03:53:58] * mps (mp@178.79.142.101) Quit (Remote host closed the connection)
  • [03:55:53] * yates (~user@nc-71-54-138-0.dhcp.embarqhsd.net) has joined #beagleboard
  • [03:56:06] * yates (~user@nc-71-54-138-0.dhcp.embarqhsd.net) has joined #beagle
  • [04:00:21] <jkridner_> koen: I suspect Mac needs CDC instead of or in addition to RNDIS. I'm giving that a shot. Building now.
  • [04:02:05] <yates> are daughtercards interfacing via the P9 expansion connector on the beagleboard xm required to have an eeprom for pin muxing?
  • [04:04:52] <jkridner_> the beagleboard-xm kernel doesn't have an EEPROM format to define pin muxing as far as I know.
  • [04:05:02] <jkridner_> you have to use buddy= in your kernel command line.
  • [04:05:55] <jkridner_> or set the pin muxing at run-time if there isn't already kernel support for your hardware.
  • [04:06:33] <jkridner_> seems like something we can go back and support with not-capebus soon (TM)
  • [04:06:45] <yates> i guess i'm totally confused about this.
  • [04:06:52] * emeb_mac (~ericb@ip72-201-78-226.ph.ph.cox.net) has joined #beagle
  • [04:06:57] <yates> what data does the eeprom provide?
  • [04:07:24] <jkridner_> EEPROM isn't required on BeagleBoard-xM beagle-buddy boards, only BeagleBone capes
  • [04:07:48] <yates> by "beagle-buddy" do you mean P9 interfaces?
  • [04:08:00] <yates> i'm on the rev c.1.0
  • [04:08:01] <jkridner_> oh, wait...
  • [04:08:07] <jkridner_> I forgot, we did define an EEPROM standard.
  • [04:08:08] <yates> of the bbxm
  • [04:08:15] <jkridner_> my bad... man am I out of whack.
  • [04:08:20] <yates> np.
  • [04:08:20] <jkridner_> http://elinux.org/BeagleBoardPinMux#EEPROM_content
  • [04:08:35] <yates> i very much appreciate your help, jkridner_
  • [04:09:08] <jkridner_> wow, there's several more boards since the last time I looked.
  • [04:09:33] <yates> i'm still pretty confused
  • [04:09:40] <yates> how does the eeprom get programmed?
  • [04:11:08] <yates> it looks like it connects to the i2c bus on the board
  • [04:11:08] <jkridner_> you can write to it from the command-line if it wasn't previously programmed.
  • [04:11:15] <jkridner_> yes, it does.
  • [04:11:17] <yates> via linux?
  • [04:12:11] <jkridner_> yes, or u-boot, but typically Linux.
  • [04:13:04] <yates> so basically the information you write tells which gpio's to output to which bga pins, and thus which gpios go out to the p9 connector ?
  • [04:13:46] * mps (mp@aggr.com) has joined #beagle
  • [04:14:10] <jkridner_> or other functions.
  • [04:14:39] <mrpackethead_> jkridner_: thanks, that was a question i was going to have to ask shorlty
  • [04:14:42] <mrpackethead_> about the EEPROM
  • [04:14:47] * harshpb (~harshpb@122.167.242.222) Quit (Remote host closed the connection)
  • [04:15:35] * emeb (~ericb@ip72-201-78-226.ph.ph.cox.net) Quit (Quit: Leaving.)
  • [04:16:36] * jkridner_ thinks we need to do something to consolidate the EEPROM formats between BeagleBoard and BeagleBone to avoid long-term confusion.
  • [04:16:38] <jkridner_> :(
  • [04:16:56] <jkridner_> the two formats are totally different.
  • [04:17:04] <mrpackethead_> the beagleboard is probably a dead duck though?
  • [04:17:30] <yates> mrpackethead_: do you mean the bbxm?
  • [04:17:42] <jkridner_> well, it is harder to get attention on it lately, but there are still a ton of people buying them and I get requests to get the newer software running on it kinda frequently.
  • [04:17:51] <jkridner_> the kernel's been revved pretty well.
  • [04:18:13] <yates> jkridner_: by the way, i've gotten 3.7.4 to boot on the bbxm just yesterday.
  • [04:18:23] <jkridner_> so, 3.8 works on BeagleBoard and BeagleBoard-xM with no patches required and only a few patches really important to have.
  • [04:18:33] <mrpackethead_> what i want is a beaglebone, that had access to the the PRU's MII ports.
  • [04:18:49] <mrpackethead_> i really want to have a linux bases system with ethercat
  • [04:19:25] <jkridner_> mrpackethead_: are the pins used elsewhere on the bone design, or could they potentially be brought out to existing pins (and enabled through muxing)?
  • [04:19:30] <yates> jkridner_: do you have any specific info on getting the LSR TiWi-ble running via a com6l adapter and com6l-ble board?
  • [04:19:34] <jkridner_> if they are used, it'll never happen.
  • [04:19:49] <mrpackethead_> jkridner_: sadly, its 4 pins short..
  • [04:19:56] <mrpackethead_> which are just not connected
  • [04:19:57] <jkridner_> if they can be added to other pins and muxing would avoid interference, there is a chance.
  • [04:20:21] <jkridner_> if they are totally N/C, you could probably propose on the list what pins they could be joined with.
  • [04:20:27] * fusion94 (~fusion94@pdpc/supporter/student/fusion94) Quit (Quit: Linkinus - http://linkinus.com)
  • [04:20:43] <mrpackethead_> jkridner_: are you familar with the ICE board?
  • [04:20:59] <jkridner_> Rev A6 has some of these pins where there are 2 balls connected to a single expansion header pin.
  • [04:21:10] <mrpackethead_> jkridner_: , i saw that
  • [04:21:10] <jkridner_> I've seen it, but I don't know much about it.
  • [04:21:24] <mrpackethead_> that is a clever idea
  • [04:21:28] <mrpackethead_> :-)
  • [04:22:21] <mrpackethead_> i just loaded Orcad last night and was looking at the design.
  • [04:22:42] <mrpackethead_> i noted that quite a lot of the pins had been done like that
  • [04:22:54] <mrpackethead_> i was even thinking of doing a custom build...
  • [04:23:03] <mrpackethead_> converting beagle from 6 to 8 layers
  • [04:23:18] <mrpackethead_> picking up the extra pins
  • [04:24:23] <mrpackethead_> and pushign them out to some PHY ports
  • [04:24:36] <mrpackethead_> so it wuld be very beagle, and very ICE, but all togehter.
  • [04:26:00] <jkridner_> sounds like a nice board
  • [04:26:09] <jkridner_> but a bit more expensive
  • [04:34:57] <mrpackethead_> yes..
  • [04:35:16] <mrpackethead_> jkridner_: sorry i asked you a question in PM..
  • [04:35:26] <mrpackethead_> in case you did'tn want to answer it in public.
  • [04:35:49] <jkridner_> I'm employed by TI and I'm one of the founders of BeagleBoard.org
  • [04:35:55] <mrpackethead_> ahh.. ok.
  • [04:36:09] <mrpackethead_> cool, your comments lead me to think that
  • [04:36:11] <mrpackethead_> :-)
  • [04:36:23] <jkridner_> I didn't do the hardware design, but I spec'd out features and I try to be the community face.
  • [04:36:33] <mrpackethead_> i'm just regretting we did'nt latch on to it earlier.
  • [04:36:53] <jkridner_> Gerald designed the hardware. He's more (very) responsive on the mailing list.
  • [04:37:08] <mrpackethead_> i've talked with Gerald a few times.
  • [04:37:10] <jkridner_> koen did the distro
  • [04:37:34] <mrpackethead_> i'm running in debian
  • [04:37:38] <jkridner_> people who have worked on the kernel are many, many, many and varied.
  • [04:37:43] <jkridner_> k.
  • [04:37:49] <mrpackethead_> the *only* reaosn why, is its because what i was familar with
  • [04:38:04] <mrpackethead_> and as yet, hav'nt come unstuck.
  • [04:38:16] <jkridner_> rcn-ee has done an amazing job at making sure there are good write-ups on running Ubuntu, Debian and Fedora
  • [04:38:29] <mrpackethead_> yes, in deed
  • [04:38:35] <mrpackethead_> his net-installer is very good as well
  • [04:38:42] * yates (~user@nc-71-54-138-0.dhcp.embarqhsd.net) has left #beagleboard
  • [04:39:16] * jkridner_ gives up on g_multi on Mac for the moment and spends some time with the wife
  • [04:39:29] <mrpackethead_> ;:-)
  • [04:39:33] <mrpackethead_> you gotta do that
  • [04:39:56] <alan_o> mranostay: hehe. I'm famous now :)
  • [04:40:19] <mrpackethead_> alan_o: i'm a hobbit. beat that
  • [04:41:21] <mrpackethead_> jkridner_: i'll take another look at the pin muxing
  • [04:41:25] <mrpackethead_> and see what was missing.
  • [04:41:28] <mrpackethead_> and see if its possible
  • [04:41:55] <mrpackethead_> anyone else fmailar with Ethercat?
  • [04:43:26] <yates> jkridner_: regarding pin muxing and the expansion header eeprom, i still have a couple of clarifications to ask: 1) doesn't the eeprom only have to be written once? and 2) is the idea that linux, when configured for the omap3 and this board, will read the eeprom on initialization and set the pinmux as specified by the eeprom data?
  • [04:48:48] <yates> also, it looks like beagle suggests the eeprom is hardware write-protected, so how would you ever write it unless you physically changed the board?!?
  • [04:49:56] <yates> jkridner_: ps: i was contracting at TI last year (Dallas, Forest/TI Blvd), for Susan Yim in the SmartGrid group
  • [04:54:18] <yates> jkridner_: hello?
  • [04:55:50] * GPSFan (~kenm@64.92.145.112) Quit (Remote host closed the connection)
  • [05:02:11] <mrpackethead_> yates: hes gone to talk to his wife
  • [05:02:52] <yates> oh. that's a good thing(TM)
  • [05:03:10] <yates> mrpackethead_: do you knwo about this eeprom thing?
  • [05:03:20] <mrpackethead_> i know that i need to know about it shortly.
  • [05:03:22] <mrpackethead_> :-)
  • [05:03:25] <mrpackethead_> thats not the same thign
  • [05:03:37] <mrpackethead_> post to the beagle mailing list
  • [05:03:40] <mrpackethead_> someone will answer
  • [05:03:44] <yates> is the idea that the mfr programs it with the correct information, and the linux kernel does a read-only to determine how to configure the pinmux?
  • [05:03:45] <mrpackethead_> and generally quite quickly
  • [05:04:00] <mrpackethead_> i understand that is how it works
  • [05:04:08] <mrpackethead_> i've seen a format of the data as well
  • [05:04:14] <mrpackethead_> your supposed to register 'capes'
  • [05:04:56] <yates> capes/daughtercards/wingboards/blah blah blah
  • [05:05:05] <yates> another cutesie term for the decade...
  • [05:05:27] <yates> mezzanine boards
  • [05:06:35] <yates> yeah, apparently the format is here: http://elinux.org/BeagleBoardPinMux#EEPROM_content
  • [05:07:45] * alan_o (~alan@c-68-62-254-211.hsd1.fl.comcast.net) Quit (Quit: Leaving)
  • [05:11:41] * hark (~hark@w.v89.eu) Quit (Ping timeout: 245 seconds)
  • [05:12:18] * hark (~hark@w.v89.eu) has joined #beagle
  • [05:17:59] * totty (~chatzilla@p5DCA016B.dip0.t-ipconnect.de) has joined #beaglebone
  • [05:17:59] * totty (~chatzilla@p5DCA016B.dip0.t-ipconnect.de) has joined #beagle
  • [05:20:30] * mrpackethead_ (~mrpacketh@118-93-95-178.dsl.dyn.ihug.co.nz) Quit (Remote host closed the connection)
  • [05:20:56] * mrpackethead_ (~mrpacketh@118-93-95-178.dsl.dyn.ihug.co.nz) has joined #beagle
  • [05:21:37] * dj_pi (~asd@c-107-5-25-243.hsd1.mi.comcast.net) Quit (Ping timeout: 248 seconds)
  • [05:22:01] <yates> is there a linux command line utility for reading i2c devices?
  • [05:22:23] <yates> LSR told me it's possible i have an unprogrammed card. Pffft!
  • [05:25:39] * mrpackethead_ (~mrpacketh@118-93-95-178.dsl.dyn.ihug.co.nz) Quit (Remote host closed the connection)
  • [05:25:46] * mrpackethead_ (~mrpacketh@118-93-95-178.dsl.dyn.ihug.co.nz) has joined #beagle
  • [05:29:33] * tema (~tema@92-100-173-72.dynamic.avangarddsl.ru) has joined #beagle
  • [05:37:18] * mrpackethead_ (~mrpacketh@118-93-95-178.dsl.dyn.ihug.co.nz) Quit (Ping timeout: 264 seconds)
  • [05:37:20] * paddu (0e604be4@gateway/web/freenode/ip.14.96.75.228) has joined #beagle
  • [05:37:36] <paddu> haii
  • [05:38:45] <paddu> i want to do ne simple project UART in DM3730
  • [05:39:04] <paddu> any boday can help?
  • [05:40:57] <dm8tbr> do you have a linux desktop?
  • [05:41:24] <mranostay> heh
  • [05:41:33] <paddu> no i am using CCsv5
  • [05:41:54] <paddu> i used to write code in c language
  • [05:42:26] <dm8tbr> that's great, then just look up the linux serial programming howto and get kicking
  • [05:42:33] * mrpackethead_ (~mrpacketh@118-93-95-178.dsl.dyn.ihug.co.nz) has joined #beagle
  • [05:43:42] * KeatonT (~textual@unaffiliated/keatont) has joined #beagle
  • [05:44:11] <paddu> ha i know the methadalogy of UARt but i tried to initialize the UART register the values i wrote is don't go to that perticular regitsers
  • [05:45:06] * KeatonT (~textual@unaffiliated/keatont) Quit (Client Quit)
  • [05:45:50] <paddu> u has idea about DM3730 in that for UART e have some regitsers na MDR1_REG,DLL_REG,SYSC_REG,etc in that regitsers i won;t write
  • [05:47:14] <paddu> befor this project i did one timer(PWM) priject in that also have some registrs like that that i can accessed easiley but in this i don't know y like this?
  • [05:49:56] <paddu> hello Ruecker r u there??????
  • [05:50:11] * dj_pi (~asd@c-107-5-25-243.hsd1.mi.comcast.net) has joined #beagle
  • [05:50:17] * mranostay takes shot
  • [05:50:37] <mranostay> dm8tbr: see what you did?
  • [05:51:05] <paddu> what?
  • [05:52:11] <paddu> from monday to this day am seeing the difference but no use
  • [05:54:32] <dm8tbr> paddu: adressing me by my last name does not get you anything.
  • [05:55:28] <dm8tbr> paddu: and you didn't mention you were trying to write something on bare metal. We use Linux for such things...
  • [05:56:17] * dj_pi (~asd@c-107-5-25-243.hsd1.mi.comcast.net) Quit (Ping timeout: 248 seconds)
  • [05:57:28] <paddu> what is bare metal?
  • [05:57:39] <dm8tbr> 'without an OS'
  • [05:58:34] <paddu> no
  • [06:03:21] * sh1v (~sh1v@confluxhost.com) Quit (Quit: Lost terminal)
  • [06:03:50] <paddu> k bye
  • [06:05:02] * jimboy (~jimboy@66-238-71-212.starstream.net) has joined #beaglebone
  • [06:05:04] * jimboy (~jimboy@66-238-71-212.starstream.net) has joined #beagle
  • [06:19:54] * KeatonT (~textual@unaffiliated/keatont) has joined #beagle
  • [06:23:28] * paddu (0e604be4@gateway/web/freenode/ip.14.96.75.228) Quit (Quit: Page closed)
  • [06:24:25] * KeatonT (~textual@unaffiliated/keatont) Quit (Client Quit)
  • [06:55:48] * tema (~tema@92-100-173-72.dynamic.avangarddsl.ru) Quit (Ping timeout: 248 seconds)
  • [06:59:41] * totty (~chatzilla@p5DCA016B.dip0.t-ipconnect.de) Quit (Ping timeout: 256 seconds)
  • [07:07:14] * lyakh (~lyakh@dslb-094-221-098-036.pools.arcor-ip.net) has joined #beagle
  • [07:18:12] * Ceriand|desktop (~Ceriand@unaffiliated/ceriand) Quit (Quit: Leaving.)
  • [07:18:20] * _roger_ (~a0740758@nat/ti/x-toamnuijyqzhzyke) has joined #beagle
  • [07:24:31] * NulL (~bleh1@80.65.242.171) has joined #beagle
  • [07:24:54] * NulL is now known as Guest18972
  • [07:27:30] <mrpackethead_> yates, still here
  • [07:28:23] * hattwick (~hattwick@68-184-17-253.dhcp.unas.ma.charter.com) Quit (Ping timeout: 246 seconds)
  • [07:30:41] * jpirko (~jirka@ip-94-112-98-141.net.upcbroadband.cz) has joined #beagle
  • [07:32:27] <panto> gm trolls
  • [07:32:51] * Guest18972 (~bleh1@80.65.242.171) Quit (Ping timeout: 240 seconds)
  • [07:33:24] * NulL (~bleh1@87.254.68.140) has joined #beagle
  • [07:33:35] <emeb_mac> who's that on the bridge?
  • [07:33:48] * NulL is now known as Guest23301
  • [07:34:17] * emeb_mac (~ericb@ip72-201-78-226.ph.ph.cox.net) Quit (Quit: emeb_mac)
  • [07:39:26] * woglinde (~henning@g225074090.adsl.alicedsl.de) has joined #beagle
  • [07:41:44] <mrpackethead_> panto: theres hobbits here as well
  • [07:42:13] <mranostay> panto: someone was asking about capemgr here even
  • [07:46:13] <panto> I sorta see something
  • [07:46:20] <panto> but I guess he's not around now
  • [07:47:35] * mranostay pokes av500
  • [07:48:25] <mrpackethead_> i was asking about it actually
  • [07:48:31] <mrpackethead_> i'm quite interested to know how it works
  • [07:48:45] <mranostay> or mrpackethead_
  • [07:48:47] <mranostay> er
  • [07:48:56] <mranostay> rather mru
  • [07:49:04] <panto> mrpackethead_, well, what do you want to know?
  • [07:49:07] <mrpackethead_> mrpackethead the simple hobbit from middle-earth
  • [07:49:30] <mrpackethead_> im trying to get up to speed on Device Tree, how that works and how the capemgr fits in to that
  • [07:50:45] * mranostay goes to sleep reading this shitty intel spec for work..
  • [07:51:03] <mranostay> no offense to the intel guys here :)
  • [07:52:29] <panto> mrpackethead_, there are a bunch of articles on lwn.net
  • [07:52:46] <panto> there's some documents in Documentation/devicetree as well
  • [07:53:15] <mranostay> panto: exact steps?
  • [07:53:27] * panto kicks mranostay to bed
  • [07:57:04] * woglinde (~henning@g225074090.adsl.alicedsl.de) Quit (Ping timeout: 246 seconds)
  • [07:57:06] <mrpackethead_> thanks panto
  • [07:57:41] <mrpackethead_> there is a big learing curve with this stuff
  • [07:57:59] <mrpackethead_> but 'm resoanbly pleased with how fast i've got stuff done
  • [07:58:28] <av500> mranostay: yup
  • [07:58:29] <panto> mrpackethead_, they tend to scare you away with big words, but it's just a tree data structure
  • [07:58:47] <mrpackethead_> got my head around pin muxing today
  • [07:58:58] <mrpackethead_> and got some square waves on the scope
  • [07:58:59] * av500 waits to learn DT until it is a systemd module
  • [07:59:07] <panto> mrpackethead_, right, that's the whole idea - it's a bit weird at first, but after you get a hang of it, it's much easier to do
  • [07:59:22] <mrpackethead_> whats the deal with capes
  • [07:59:29] <mrpackethead_> and the eeprom
  • [08:00:05] <mrpackethead_> thats my other question for today
  • [08:00:26] <mrpackethead_> are they a way of indentifying the cape?
  • [08:00:33] * jacekowski (jacekowski@jacekowski.org) Quit (Read error: No route to host)
  • [08:00:36] * rsalveti (~rsalveti@unaffiliated/rsalveti) Quit (Ping timeout: 248 seconds)
  • [08:02:35] <KotH> mrpackethead_: there is this document that describes DT for the ppc arch
  • [08:02:50] <KotH> mrpackethead_: have a look at that, it covers most of the basics you need to know
  • [08:03:00] <ka6sox> mrpackethead_, think autoconf for hardware :D
  • [08:03:46] <mrpackethead_> so, Device tree is a collection of data that availabel to the OS about the hardware that is connected to it?
  • [08:03:49] <panto> mrpackethead_, yes, if you setup your EEPROM data correctly, and provide a matching dtbo binary blob firmware
  • [08:03:53] <mrpackethead_> and its capablality.. etc
  • [08:03:59] <panto> right
  • [08:04:18] <panto> there's a whole bunch of details, but you don't have to care about them
  • [08:04:53] <panto> if you look into Documentation/devicetree/bindings/ you'll see documents that (should) describe each device's supported bindings
  • [08:05:24] <mrpackethead_> so, is there some kind of "registration" for capes
  • [08:05:48] <mrpackethead_> so, that if you buy my cape, it won't conflict with another cape?
  • [08:05:51] <panto> mrpackethead_, the capeloader will read the EEPROM, and request a dtbo matchine the part-number and it's revision
  • [08:06:16] <panto> mrpackethead_, it might conflict, there are a limited number of pins on the connectors
  • [08:06:45] <panto> but, if there is a conflict pinmux will fail, so you run less risk of blowing up
  • [08:06:59] <mrpackethead_> ie, if panto creates a troll-cape and gives it an ID of #1, and i create bacon-cape and give it an ID of #1..
  • [08:07:15] <panto> mrpackethead_, it's not using IDs
  • [08:07:16] <mrpackethead_> there is a conflict, becuase capeloader woudl see two thigns the same
  • [08:07:25] <panto> it's using PART-NUMBERs
  • [08:07:28] <mrpackethead_> ok..
  • [08:07:32] <mrpackethead_> Part-number or ID..
  • [08:07:36] <panto> which are short ascii fragments
  • [08:07:41] <mrpackethead_> so, does someone issue part-numbers
  • [08:07:47] <mrpackethead_> or do we just make them up
  • [08:08:02] <panto> mrpackethead_, well, you just make them up
  • [08:08:31] <panto> but to sell those capes via CCO or some other distributor you'll have to make sure there's no conflict
  • [08:08:40] <panto> which frankly is trivial
  • [08:08:54] <mrpackethead_> yes, there shoudl be plenty of partnumers
  • [08:08:56] <panto> just put something like a company prefix and you're set
  • [08:09:10] <mrpackethead_> untill one day..
  • [08:09:16] <panto> if you can't track part numbers for your own capes you have other problems :)
  • [08:09:24] <mrpackethead_> yup
  • [08:09:26] <mrpackethead_> understand
  • [08:10:00] <mrpackethead_> so, cape gets powered up for first time
  • [08:10:05] <mrpackethead_> eemprom is empty
  • [08:10:08] <panto> so, sanity is enforced via common sense and not via a shotgun
  • [08:10:10] <mrpackethead_> you need to write it.
  • [08:10:21] <mrpackethead_> appropraitely
  • [08:10:30] <mrpackethead_> and then do you lock it to RO ?
  • [08:10:35] <panto> mrpackethead_, you can force load a cape definition btw even when there's no EEPROM
  • [08:10:51] <mrpackethead_> or do you just have to be sensible not to destroy it
  • [08:11:03] <panto> typically people put a jumper to the eeprom write pin
  • [08:11:23] <panto> so when they want to write the EEPROM jumper it
  • [08:12:04] <mrpackethead_> ok..
  • [08:12:18] * Guest23301 (~bleh1@87.254.68.140) Quit (Ping timeout: 276 seconds)
  • [08:12:26] <mrpackethead_> i see that there is also often some dip switches
  • [08:12:34] <mrpackethead_> attacehd to the EEPROM
  • [08:12:37] <panto> mrpackethead_, you can write it via sysfs
  • [08:12:47] <mrpackethead_> is that so you could stack several of the same cape
  • [08:12:54] <mrpackethead_> but address them differently?
  • [08:13:24] * shoragan (~jlu@2001:6f8:1178:2:219:99ff:fe56:8d7) has joined #beagle
  • [08:13:25] * shoragan (~jlu@2001:6f8:1178:2:219:99ff:fe56:8d7) Quit (Changing host)
  • [08:13:25] * shoragan (~jlu@debian/developer/shoragan) has joined #beagle
  • [08:13:26] * damir__ (~damir@217-72-91-162.ipv4.tusmobil.si) has joined #beagle
  • [08:14:07] <panto> hmm, so, there's write method exported via sysfs
  • [08:14:09] <mrpackethead_> my cape design is quite a big 2nd project.
  • [08:14:15] <panto> nm, you just use a tool
  • [08:14:18] <mrpackethead_> i hope i hav'nt bitten off too much!
  • [08:14:36] <panto> mrpackethead_, yes, you can stack up to 4 capes for auto-detection
  • [08:14:51] <panto> the way they are differentiated is via their eeprom addresses
  • [08:15:10] <mrpackethead_> ok..
  • [08:15:12] <mrpackethead_> catching on
  • [08:15:13] <panto> hex addresses 54-57
  • [08:15:18] <mrpackethead_> i try to only ask the questions one.
  • [08:15:19] <mrpackethead_> :-)
  • [08:15:26] <panto> on the i2c2 bus
  • [08:15:39] <mrpackethead_> along with the dreaded RTC
  • [08:15:54] <panto> so again, most capes have a dip switch that allows you to switch addresses
  • [08:16:16] <mrpackethead_> somthign about this community that is quite interesting is some topics seem to invoke massive amounts of discussion..
  • [08:16:20] <mrpackethead_> when they seem simple.
  • [08:16:40] <mrpackethead_> lol.
  • [08:16:40] <panto> we all have strong opinion about the color of the bike shed
  • [08:16:45] <mrpackethead_> yup.
  • [08:16:51] <mrpackethead_> i have noted..
  • [08:17:43] <panto> err, so I was wrong again; the sysfs interface do allows writes
  • [08:18:24] <panto> so writing the eeprom should be as simple as preparing a file with a hex editor and catting to >eeprom of the device directory in sysfs
  • [08:18:44] <mrpackethead_> ahh
  • [08:18:45] <mrpackethead_> ok.
  • [08:18:47] <mrpackethead_> thats good to know
  • [08:21:22] <mrpackethead_> panto: do you ahve an opinion on Real Time Clocks?
  • [08:21:31] <mrpackethead_> hopefully teh trolls won't make too much noise
  • [08:21:33] <ka6sox> back to round 3 of DT Wars.
  • [08:21:34] <panto> they have to keep time accuratle
  • [08:21:35] <mrpackethead_> they are probably asleep
  • [08:21:37] <panto> *accurately
  • [08:21:54] <mrpackethead_> ka6sox: you've had your turn :-)
  • [08:22:28] <ka6sox> mrpackethead_, I've been around 3 turns so far and no luck.
  • [08:22:36] <ka6sox> I keep missing "yet another thing"
  • [08:22:52] <mrpackethead_> i'm proposing to stick a batery backed up DS1339 on teh I2C buss
  • [08:23:59] <ka6sox> mru, putting 3 trees in tmpfs is excellent
  • [08:24:22] <mrpackethead_> reading it sometime while the init.d scripts are running
  • [08:24:29] <mrpackethead_> and setting the clock when we start up
  • [08:24:41] <mrpackethead_> does that sound resoanble
  • [08:25:20] <av500> hmm
  • [08:25:31] <av500> a clock on i2c should be know to the kernel, no?
  • [08:25:41] <ka6sox> yes
  • [08:25:41] <av500> so why does user space need to deal with it?
  • [08:25:45] <mrpackethead_> i dnt' know.
  • [08:25:48] <mrpackethead_> doe it
  • [08:25:51] <mrpackethead_> or does it not
  • [08:25:55] * florian_kc (~fuchs@port-217-146-132-69.static.qsc.de) has joined #beagle
  • [08:25:55] * florian_kc (~fuchs@port-217-146-132-69.static.qsc.de) Quit (Changing host)
  • [08:25:56] * florian_kc (~fuchs@Maemo/community/contributor/florian) has joined #beagle
  • [08:25:57] <av500> should be handled like a RTC on a motherboard
  • [08:25:58] <ka6sox> it goes thru sysfs.
  • [08:26:17] <av500> on my PC, I do not read RTC in init.d
  • [08:26:43] <ka6sox> doesn't it read it in rc.S?
  • [08:26:44] <mrpackethead_> no, but you may well get time via ntp in userspace
  • [08:26:50] <av500> sure
  • [08:27:34] <mrpackethead_> so, is there much difference between getting time via NTP or from a local RTC
  • [08:27:40] * florian_kc is now known as florian
  • [08:28:03] <av500> imagine a non-networked PC
  • [08:28:11] <av500> when it boots, it gets the time from the motherboard
  • [08:28:17] * ant_work (~ant@host6-80-static.42-85-b.business.telecomitalia.it) has joined #beagle
  • [08:28:18] <av500> does that happen in init.d?
  • [08:28:26] <av500> or does the kernel know about the RTC?
  • [08:28:37] <mrpackethead_> i dont' know
  • [08:28:39] <koen> heh
  • [08:28:40] <ka6sox> it knows how to read it
  • [08:28:48] <koen> 2 XXL t-shirts for FOSDEM
  • [08:28:54] <koen> ehm
  • [08:28:55] <koen> 5
  • [08:29:01] <koen> better than nothing
  • [08:29:12] <ka6sox> true
  • [08:29:14] * av500 raises hans
  • [08:29:16] * av500 raises hand
  • [08:29:17] <av500> too
  • [08:29:30] <mrpackethead_> av500: so you are tyically saying that the time is normally read by the kernel
  • [08:29:39] <koen> I do have beagle shaped 1GB usb sticks
  • [08:29:51] <mrpackethead_> (if its coming from an onboard RTC )
  • [08:29:56] <av500> koen: 1GB for real or 1GB in partition table only?
  • [08:30:33] * av500 has a quad core A7 now
  • [08:31:14] <mrpackethead_> so, if i start my beagle up right now
  • [08:31:26] <mrpackethead_> and its not attached to the network
  • [08:31:39] <koen> av500: the label says "1GB - made in china"
  • [08:31:39] <mrpackethead_> what time will it have
  • [08:31:52] <av500> koen: ok, the latter :)
  • [08:35:18] <av500> mrpackethead_: what I am saying is: on a PC, the kernel knows about the RTC
  • [08:35:24] <av500> and can handle it
  • [08:35:35] <av500> so a fixed RTC on I2C should be no different
  • [08:35:38] * tema (~tema@92-100-173-72.dynamic.avangarddsl.ru) has joined #beagle
  • [08:35:48] <mrpackethead_> but its not a pac
  • [08:35:49] <mrpackethead_> pc
  • [08:35:50] <panto> av500, it should be exactly the same
  • [08:36:04] <panto> mrpackethead_, that makes no difference to the kernel
  • [08:36:10] <mrpackethead_> true
  • [08:39:25] <mrpackethead_> grr.. now this bone crashes!!
  • [08:40:28] <mrpackethead_> i foolishly pulled the plug on it
  • [08:40:35] <mrpackethead_> and now she don't reboot
  • [08:40:37] <mrpackethead_> i hate that
  • [08:41:33] <mrpackethead_> that is a real problem
  • [08:42:51] <mrpackethead_> panto: av500 i can understand the logic of why the kernel shoudl read the RTC
  • [08:43:03] <mrpackethead_> but its not the only way is it?
  • [08:43:14] <panto> it is the easiest
  • [08:43:45] <panto> put your clock chip on the i2c bus, make the DT entry, and poof it should work
  • [08:44:25] <mrpackethead_> i've actually got no reason not to do that
  • [08:45:34] <mrpackethead_> mmm, somethigns got corrupted
  • [08:45:46] <mrpackethead_> INIT: version 2.88 booting
  • [08:45:46] <mrpackethead_> Using makefile-style concurrent boot in runlevel S.
  • [08:45:55] <mrpackethead_> and then she just sits
  • [08:46:37] <mrpackethead_> panto: i guess my real problem is I ahve no unerstanding of how the kernel works
  • [08:46:45] <mrpackethead_> or how to modify or change it
  • [08:46:50] <mrpackethead_> and the implicatiosn of all that
  • [08:47:05] <panto> mrpackethead_, you got some reading ahead of you then :)
  • [08:47:36] <mrpackethead_> yup.
  • [08:48:28] <mrpackethead_> ok, so i now udnerstnad why it seems sensible to get the kernel to find the RTC
  • [08:51:23] * jsabeaudry (~jsabeaudr@242.161.18.64.static.oricom.ca) Quit (Ping timeout: 245 seconds)
  • [08:53:10] * jpsaman (~jpsaman@51-200-ftth.onsbrabantnet.nl) has joined #beagle
  • [08:53:10] * jpsaman (~jpsaman@51-200-ftth.onsbrabantnet.nl) Quit (Changing host)
  • [08:53:10] * jpsaman (~jpsaman@videolan/developer/jpsaman) has joined #beagle
  • [08:53:11] * damir__ (~damir@217-72-91-162.ipv4.tusmobil.si) Quit (Quit: Leaving.)
  • [08:53:19] * calculu5 (~calculus@gentoo/user/calculus) has joined #beagle
  • [08:56:23] * damir__ (~damir@217-72-91-162.ipv4.tusmobil.si) has joined #beagle
  • [08:56:36] * calculus (~calculus@gentoo/user/calculus) Quit (Ping timeout: 248 seconds)
  • [08:57:41] * mrpackethead_ (~mrpacketh@118-93-95-178.dsl.dyn.ihug.co.nz) Quit (Read error: Connection reset by peer)
  • [08:58:01] * mrpackethead_ (~mrpacketh@118-93-95-178.dsl.dyn.ihug.co.nz) has joined #beagle
  • [08:58:01] * jsabeaudry (~jsabeaudr@242.161.18.64.static.oricom.ca) has joined #beagle
  • [09:01:49] * mythos (~mythos@unaffiliated/mythos) Quit (Ping timeout: 246 seconds)
  • [09:14:14] * W1N9Zr0 (~W1N9Zr0@24.212.193.98) Quit (Remote host closed the connection)
  • [09:14:55] * mhaberler (~mhaberler@macbook.stiwoll.mah.priv.at) has joined #beagle
  • [09:14:55] * mhaberler (~mhaberler@macbook.stiwoll.mah.priv.at) has joined #beaglebone
  • [09:18:38] * KidBeta (~KidBeta@150.203.64.13) has joined #beagle
  • [09:31:17] * mthalmei_away is now known as mthalmei
  • [09:31:19] <KotH> av500: hmm? the kernel doesnt read the rtc, afaik... it's hwclock that does it
  • [09:31:28] <KotH> av500: unless i'm gravely mistaken
  • [09:34:33] <panto> KotH, Documentation/rtc.txt
  • [09:35:42] * ncbas (~ncbas@63-11.bbned.dsl.internl.net) has joined #beagle
  • [09:35:45] * ncbas is now known as modmaker
  • [09:37:12] <panto> and CONFIG_RTC_HCTOSYS
  • [09:37:31] * Zju (~abaddon@178.121.106.198) Quit (Ping timeout: 246 seconds)
  • [09:37:56] <KotH> panto: i'm currently reading the kernel sources
  • [09:38:48] * mthalmei is now known as mthalmei_away
  • [09:39:20] * tema_ (~tema@95-55-116-156.dynamic.avangarddsl.ru) has joined #beagle
  • [09:40:14] <panto> check drivers/rtc/hctosys.c
  • [09:40:21] * tema (~tema@92-100-173-72.dynamic.avangarddsl.ru) Quit (Ping timeout: 276 seconds)
  • [09:40:52] * Zju (~abaddon@178.121.106.198) has joined #beagle
  • [09:41:10] * hattwick (~hattwick@68-184-17-253.dhcp.unas.ma.charter.com) has joined #beagle
  • [09:41:32] * Wipster (~Wip@host81-137-80-202.in-addr.btopenworld.com) has joined #beagle
  • [09:41:51] <KotH> panto: domo
  • [09:41:55] <KotH> av500: i am gravely mistaken
  • [09:42:12] <panto> historically, yes, the kernel didn't
  • [09:42:29] <panto> it turns out it's easier to have him do it
  • [09:44:32] <KotH> juup, files says (c) 2005
  • [09:44:36] <KotH> that's not that long ago
  • [09:44:43] <av500> ic
  • [09:44:50] <av500> I thought it was done by kernel always
  • [09:45:25] <panto> histerical reasons on the pc
  • [09:46:42] <av500> ic
  • [09:47:40] <Russ> mrpackethead_, I keep tellin' ya, hwclock.sh
  • [09:50:42] <mrpackethead_> Russ, so your telling me somerhign differnet from Av500 and panto
  • [09:51:15] <panto> mrpackethead_, no, it's the same thing
  • [09:51:33] <panto> hwclock will use any hardware clock device
  • [09:52:36] <mrpackethead_> sorry, i thought hwclock was in userspace?
  • [09:52:44] <mrpackethead_> is it in the kernel?
  • [09:53:13] <Russ> its a userspace way of setting system time by a clock
  • [09:53:14] <panto> it's in userspace, but it accesses the rtc device which is in the kernel
  • [09:59:03] * mythos (~mythos@unaffiliated/mythos) has joined #beagle
  • [09:59:09] <KotH> hw access is almost always in the kernel...
  • [09:59:28] <KotH> unless people use stuff like /dev/exynos-mem or x11
  • [10:01:00] * jackmitchell (~Thunderbi@195.171.99.130) Quit (Quit: jackmitchell)
  • [10:09:20] <mrpackethead_> ok, i'll put it in the kernel. ( something new to learn )
  • [10:09:22] <mrpackethead_> but..
  • [10:09:37] <mrpackethead_> if i used a differnet clock source.. ( say a GPS )
  • [10:09:46] <mrpackethead_> where woudl they live
  • [10:09:48] <mrpackethead_> ?
  • [10:14:49] <panto> GPSes are simple uarts I think (even when they are USB connected)
  • [10:15:00] <panto> it's something for the gps daemon to do then
  • [10:15:18] <av500> also a GPS might not have time when the system boots
  • [10:15:25] <panto> right
  • [10:15:30] <av500> only after getting a fix etc...
  • [10:15:53] <mrpackethead_> yup.
  • [10:16:03] <mrpackethead_> and a NTP source is similar
  • [10:16:49] <mrpackethead_> GPS should be better than a Xtal controlled RTC though
  • [10:17:00] <mrpackethead_> escp if you use a PPS
  • [10:17:13] <panto> yeah
  • [10:17:19] <KotH> mrpackethead_: most people who use external clocks like gps, dcf77, etc are feeding them trough ntp into the system
  • [10:17:34] <panto> but this is something for the user space to deal with
  • [10:17:39] <panto> it's not a kernel problem anymore
  • [10:17:40] <mrpackethead_> something has to be stratum-1
  • [10:17:42] <KotH> mrpackethead_: and gps is short term worse than an xtal
  • [10:18:15] <mrpackethead_> the best GPS's can be 18 minutes before they can come online
  • [10:18:21] <mrpackethead_> worst case
  • [10:18:30] <mrpackethead_> if they do not have a currnet alamnac
  • [10:18:31] <KotH> mrpackethead_: jitter of a good gps receiver is +/-100ns, some have even as high as 1us, timing receivers have a jitter of +/- 2-10ns, after sawtooth correction
  • [10:19:23] <KotH> and that's with good antenna positions...if the reception is bad, or part of the sky is not visible, it goes up by 1-2 orders of magnitude
  • [10:20:11] <KotH> that's why all GPSDOs use a crystal to filter the gps pps
  • [10:20:11] <mrpackethead_> im sure that the jitter is not that high in good GPS
  • [10:20:15] <KotH> it is
  • [10:20:50] <mrpackethead_> anwyay..
  • [10:21:28] <KotH> mrpackethead_: https://www.u-blox.com/images/downloads/Product_Docs/Timing_AppNote_%28GPS.G6-X-11007%29.pdf
  • [10:21:44] <KotH> mrpackethead_: that's a state of the art gps timing receiver
  • [10:22:29] <KotH> mrpackethead_: figure 2 shows you what the pps pulse looks in hw... figure 3 is after application of the sawtooth correction in software
  • [10:22:43] <KotH> mrpackethead_: and that's with very good antenna position
  • [10:22:55] <KotH> mrpackethead_: navigational receivers are quite a bit worse
  • [10:23:00] <mrpackethead_> its way more preceiosn than i need anyway
  • [10:23:31] <KotH> precision is not always what is limiting you :)
  • [10:23:36] * jimboy (~jimboy@66-238-71-212.starstream.net) Quit (Ping timeout: 276 seconds)
  • [10:23:56] <mrpackethead_> im not using a GPS
  • [10:23:59] <mrpackethead_> so not a problem
  • [10:23:59] <mrpackethead_> :-)
  • [10:24:04] <KotH> the effects of jitter are usually a lot worse than having an offset by the same amount
  • [10:27:22] <av500> KotH: my ham coworker has some GPS 10mhz thing with TCXO
  • [10:28:29] * jackmitchell (~Thunderbi@195.171.99.130) has joined #beagle
  • [10:32:07] <KotH> av500: juup, a lot of ham's use GPSDOs as precision frequency standards
  • [10:32:21] <KotH> av500: though i think you rather mean OCXO instead of TCXO :)
  • [10:34:15] <av500> yeah
  • [10:34:18] <av500> some XO
  • [10:38:11] <koen> I hate platform data in i2c clients
  • [10:38:26] <koen> especially when it's sugar like axis orientation and map
  • [10:38:49] <koen> at least have a fallback
  • [10:38:56] * koen stabs ST-E engineers
  • [10:39:11] * koen gets some napalm and sets their iglooooooo on fire
  • [10:41:41] <av500> I2S has an axis?
  • [10:41:46] <av500> I2C
  • [10:45:13] * jacekowski (jacekowski@jacekowski.org) has joined #beagle
  • [10:48:46] <koen> tilt-compensated compass
  • [10:48:54] <koen> aka magnetometer + accelerometer
  • [10:52:34] * xanium4332 (~xanium433@2001:470:1f09:10:225:90ff:fea2:995f) has joined #beagle
  • [10:52:45] <av500> koen: but what device does it expose?
  • [10:55:10] <koen> iio nodes
  • [10:56:15] <koen> I suspect it's just a mems cube internally
  • [11:19:31] * _roger_ (~a0740758@nat/ti/x-toamnuijyqzhzyke) Quit (Quit: Leaving.)
  • [11:32:11] * damir__ (~damir@217-72-91-162.ipv4.tusmobil.si) has left #beagle
  • [11:40:38] * KidBeta (~KidBeta@150.203.64.13) Quit (Quit: Computer has gone to sleep.)
  • [11:52:06] <mdp> morning
  • [11:52:21] <mdp> ugh, that was overload on techno-buzzwords for the morning
  • [11:53:10] <koen> hey mdp
  • [11:53:15] <mdp> hey
  • [11:53:17] <panto> hi mdp
  • [11:53:33] <mdp> all I hear is, "Illudium q-36 space modulator" at this point
  • [11:53:46] <mdp> hi panto
  • [11:56:32] <jkridner_> gm all
  • [11:57:26] <koen> hey jkridner_
  • [11:58:01] <panto> hi jkridner_
  • [12:03:17] <mdp> gm jkridner_
  • [12:03:29] * AndrevS (~andrevs@2001:980:55e0:1:225:b3ff:fec0:41e1) Quit (Quit: Leaving)
  • [12:03:56] * modmaker (~ncbas@63-11.bbned.dsl.internl.net) Quit (Ping timeout: 252 seconds)
  • [12:04:37] <jkridner_> koen: not sure what is up with g_multi and Mountain Lion, but I suspect we do need to turn on CDC.
  • [12:04:49] <jkridner_> I turned it on and still didn't see the network adapter.
  • [12:04:55] <jackmitchell> reading the lwn newsletter, and the article about the possibly upcoming gpiod_ functions
  • [12:05:10] * DevBot (~supybot@2001:6f8:12e0::7) Quit (Remote host closed the connection)
  • [12:05:18] * DevBot (~supybot@2001:6f8:12e0::7) has joined #beagle
  • [12:05:23] <jackmitchell> I think it would be interesting to be able to alter the names of the gpio
  • [12:05:39] <jackmitchell> for example when a driver was loaded it could take control of the gpio
  • [12:06:00] <jackmitchell> rename them to something sensible for that driver and they would be then exported in sysfs
  • [12:07:01] <jackmitchell> so a beagle cape could, for example, grab gpio 1,6,7,9 and export them as switch1_state, switch2_state, led1_state, led2_state
  • [12:07:13] <KotH> mdp: flux capacitor?
  • [12:07:24] <av500> jackmitchell: missile_launch
  • [12:07:31] <jackmitchell> but all through the gpiolib interface
  • [12:07:40] <jackmitchell> av500: :D
  • [12:07:50] <mdp> KotH: too passive, the first option can, at least, blow up the earth
  • [12:08:42] <KotH> mdp: oh.. micro black hole based warp drive turned into a weapon system?
  • [12:09:11] * av500 puts on his unobtanium jacket
  • [12:09:23] <mru> KotH: isn't that romulan tech?
  • [12:09:44] <av500> mru: they stole it from the swiss
  • [12:09:50] <panto> jackmitchell, wouldn't making only an alias in the sysfs work just the same?
  • [12:09:55] <mdp> KotH: that's on my list
  • [12:10:07] <panto> similar to ln -s I mean
  • [12:10:14] <KotH> mru: well.. the romulans use artificial black holes as an energy source for their warp drives, instead of antimatter...
  • [12:11:04] <av500> KotH: you mean they are powered by ..... bureaucracy?
  • [12:11:09] <mru> wasn't there an episode where they turned one of those into a weapon?
  • [12:11:17] <mru> or was it a cloaking device?
  • [12:11:18] <KotH> mdp: then come over here and get your black hole at CERN :)
  • [12:11:19] <mru> can't remember
  • [12:11:26] <KotH> av500: lol... yes!
  • [12:11:29] <mdp> panto, definitely policy to be solved in userspace by any typical method
  • [12:11:44] <mdp> KotH: I have a story about that, btw.
  • [12:13:06] <mdp> KotH: years ago, my now teenager woke me up at 3AM saying he could sleep because he saw the local news people talking about the possibility of the world ending.
  • [12:13:10] <KotH> mru: i'm not aware that the warp drive of any romulan was used as a weapon in an episode.. but there was one, where a pangalacitc multidimensional species that lives in the space-time plane used one of the black holes in a romulan warship to lay its eggs in... hugly distorting the time around the ship
  • [12:13:15] <mdp> s/could/couldn't
  • [12:14:09] <mdp> KotH: so we got up and had a 2 hour physics lesson together...that bored him to sleep
  • [12:14:09] <KotH> mru: but the federation used to throw out its warp drive to bomb other ships or planets a couple of times
  • [12:14:17] <KotH> mdp: lol
  • [12:14:41] <KotH> mdp: he really got disturbed by the news of the CERN ending the world?
  • [12:14:45] <mdp> KotH: young enough to not understand people joking about a current meme
  • [12:14:54] <KotH> oh..
  • [12:15:05] <mdp> KotH: he was, maybe 8 during that? I can't remember how long ago it was
  • [12:15:29] <KotH> mdp: hmm.. switch on of the lhc was iirc 3 or 4 years ago
  • [12:15:43] <KotH> mdp: i think the lawsuit was a year or two earlier
  • [12:15:44] <mdp> ok, maybe 9 then
  • [12:15:49] <mru> KotH: and how did they get home after that manoeuvre?
  • [12:15:49] <av500> KotH: no, it was like 8ys but time is running faster since then....
  • [12:15:55] <jackmitchell> mdp: panto: how would one know, when and if the driver was loaded? Would you not have to have something polling or waiting for a signal?
  • [12:16:12] <KotH> mru: that was never explained in the episodes :)
  • [12:16:19] <mdp> I recall they were discussing it not even jokingly like, "some people claim the switch-on will cause a rift and end the world!"
  • [12:16:30] <panto> you can add a new method in gpiolib that creates an alias
  • [12:16:40] <KotH> mdp: yeah...
  • [12:17:08] <mdp> KotH: at that age, they don't have the BS filter enabled yet
  • [12:17:13] <mdp> ;)
  • [12:17:14] <KotH> mdp: do you remember the crank who sued the CERN in hawaii for deliberatily putting the world at risk by creating black holes?
  • [12:17:17] <jackmitchell> ah, I was unaware that aliases could be created that easily from a kernel context
  • [12:17:22] <mdp> KotH: yes!
  • [12:17:29] <KotH> mdp: i know, i know.. i was the same at that age!
  • [12:18:32] <mdp> jackmitchell: which driver?
  • [12:18:33] <KotH> actually, it would have been more fun, if something like that would have happend in geneva
  • [12:18:46] <KotH> the lhc experiments have been a real let down
  • [12:19:02] <mru> didn't they find the higgs thing?
  • [12:19:29] <mdp> mru, higgs' bosom?
  • [12:19:34] <jackmitchell> mdp: it was a thought brought up by the gpiod_ article on lwn
  • [12:19:35] <KotH> mru: they found an energy spike that with high probability can be explained by the theory of having a higgs boson at that energy
  • [12:19:52] * kiilo (~kiilo@46-126-77-178.dynamic.hispeed.ch) has joined #beagle
  • [12:19:53] <KotH> mru: it's _not_ a proof that the higgs boson exists
  • [12:20:09] <av500> KotH: do not spoil the excitement
  • [12:20:16] <mru> well, they found something interesting at least
  • [12:20:42] <jackmitchell> mdp: essentially pondering about having dynamic descriptions of gpio's set by the driver in the kernel and exported through the gpiod_ sysfs
  • [12:21:08] <mru> besides, absolute proof that _anything_ exists is impossible
  • [12:21:16] <KotH> mru: actually very little. no new unexplainable effects, so far. the standard model as it is still holds. unless that spike is not caused by the higgs :)
  • [12:21:36] <jackmitchell> mdp: so one static description, and then a 'cosmetic' description which a driver can twiddle depending on if it has control of the gpio or not
  • [12:21:46] <mru> KotH: so it affirms the current theory
  • [12:21:52] <KotH> yes
  • [12:22:17] <KotH> the predictions of the standard model fit the data very will, as far as i have heard
  • [12:22:26] <KotH> s/will/well/
  • [12:23:00] <KotH> but then, i didnt have the time to follow all of the discussions around the lhc in the last months
  • [12:25:42] <mdp> jackmitchell: yeah, since the sysfs driver owns naming in the gpiod_ module for all exported gpios, it should be able to modify those
  • [12:26:23] <mdp> jackmitchell: it's no different than the idea that these system-specific names are expected to come in via DT/pdata
  • [12:26:33] <mdp> except...
  • [12:26:44] <mdp> it is different ;)
  • [12:27:06] <jackmitchell> mdp: yes, it's slightly different
  • [12:27:14] * DevBot (~supybot@2001:6f8:12e0::7) Quit (Remote host closed the connection)
  • [12:27:22] * DevBot (~supybot@2001:6f8:12e0::7) has joined #beagle
  • [12:27:29] <mdp> one is done at driver probe time and you could just modify DT and have it static for your system
  • [12:27:38] <mdp> the other is a runtime policy thing
  • [12:27:45] <jackmitchell> I was thinking of the am335x pin naming scheme, and how pinmuxing and such works
  • [12:27:59] <mdp> quite honestly, you are talking about something that udev does for every other device in the system
  • [12:28:03] <jackmitchell> would we not end up with mode0 names
  • [12:28:19] <jackmitchell> or that horrific long incarnation of all the pins in one name
  • [12:30:21] <jackmitchell> I suppose I am, but those names are arbitrary are they not? I don't really know the internals of udev and I'm a bit out of my depth in this conversation but udev can only name devices based on what the kernel gives it no?
  • [12:30:47] <koen> udev?
  • [12:30:49] <jackmitchell> so the 'cosmetic' name support would have to be in kernel - or your device would have to be supported in udev?
  • [12:30:55] <koen> you mean debugfs?
  • [12:31:03] <mdp> well, it operates in a different domain of creating dev nodes
  • [12:31:37] <mdp> but my point is that the implemented concept already exists of having system-specific naming driven by a userspace policy manager
  • [12:32:08] * Hoolxi (~Openfree@117.144.142.99) has joined #beagle
  • [12:32:20] <av500> koen: systemd!
  • [12:32:23] <mdp> and yes, I realize gpioX_export_link() has been around for a long time
  • [12:34:26] <mdp> jackmitchell: in any case, yes, it makes sense to want a runtime interface to create a custom link from userspace
  • [12:34:50] <mdp> as panto points out, one of those exists
  • [12:35:27] <panto> av500, admit it, you're in love with lenart
  • [12:36:00] <mdp> blossoming young love
  • [12:36:09] <panto> nothing wrong with that
  • [12:37:57] <av500> he does +1 my comments :)
  • [12:38:02] * phantoxeD (~destroy@a89-155-22-21.cpe.netcabo.pt) Quit (Ping timeout: 255 seconds)
  • [12:39:31] <panto> see, your love is not going to waste
  • [12:39:39] <panto> lucky man
  • [12:40:04] <mdp> jackmitchell: ln -sf /sys/class/gpio/gpio31 /home/sec_user/my_app/signals/space_modulator_enable_n
  • [12:40:45] <mdp> panto, it all starts with some innocent +1's
  • [12:41:09] <koen> gah, typed 'halt' out of habit instead of 'lsmod'
  • [12:41:30] <mdp> koen, no gti for that one ;)
  • [12:41:48] * phantoxeD (~destroy@a89-155-22-21.cpe.netcabo.pt) has joined #beagle
  • [12:42:15] <koen> indeed
  • [12:43:40] <koen> there, pressed reset button
  • [12:43:47] <koen> 2 stories up
  • [12:44:06] <koen> the patch from jsabeaudry to fix uboot is not working with the new musb code
  • [12:44:23] <koen> kernel oopses in musb shutdown before it reaches the restart syscall
  • [12:44:43] <mdp> awesome, shrunk edma series a lot by dropping mmc support
  • [12:45:35] * Matt_O (~MattOwnby@216.160.243.228) has joined #beagle
  • [12:47:44] <koen> I will respond to the list with vague concerns to ensure it won't make it into 3.9 and 3.10
  • [12:47:54] <mdp> koen, lol!
  • [12:47:58] <koen> then I will not respond to requests for clarification
  • [12:48:20] <koen> I have to keep my evil vendor tree relevant, you know
  • [12:48:31] <mdp> koen, the funny thing is that I don't even value mmc support ;)
  • [12:48:37] <mdp> all I need is serial and ethernet ;)
  • [12:48:45] <mdp> so no big loss to me
  • [12:51:43] <mdp> koen, working mainline would be a threat to CCO's production kernel
  • [12:51:58] <koen> that's what I said
  • [12:52:21] <mdp> I learned from jkridner, though, I massaged it to PC-biz-speak
  • [12:53:12] <mdp> koen, if the series gets close to going in you'll just have to release the Kraken
  • [12:55:19] <koen> I'll start with the hounds
  • [12:55:43] <mdp> never bring a hound to a Kraken-fight
  • [13:04:31] <bradfa> mdp, well, some of us would like mmc support :P
  • [13:04:42] <mdp> bradfa, bah
  • [13:04:54] <mdp> too controversial, you can wait
  • [13:04:57] <bradfa> mdp, multi mmc would be handy....
  • [13:05:24] <bradfa> mmc == controversial, lol
  • [13:05:30] <mdp> I would like a quiet vacation home on the moon
  • [13:05:44] <bradfa> mdp, I hear it's quiet up there
  • [13:05:49] <mdp> indeed
  • [13:05:52] <mru> the lack of atmosphere should ensure that
  • [13:05:52] <mdp> science!
  • [13:05:57] <mdp> +1
  • [13:06:17] <bradfa> science refutes your +1 with a vaguely worded paper in scientific american which you have to pay for
  • [13:06:29] <mdp> hehe
  • [13:06:30] <bradfa> paywalls, ftw!
  • [13:06:51] * bradfa wishes he could spend more time doing fun projects and less time scrambling to get product ready :(
  • [13:07:21] <bradfa> maybe if I stopped responding to the beagle phorum...
  • [13:07:41] <bradfa> which reminds me, I have to click on some links
  • [13:07:56] <mdp> bradfa, the SNR of 5 forced me to quit reading it
  • [13:08:06] <bradfa> too much signal?
  • [13:08:19] <jkridner_> koen: so, is DMA enabled?
  • [13:08:22] <bradfa> gah, google signin
  • [13:08:28] <koen> jkridner_: for what?
  • [13:08:37] <mdp> bradfa, yeah, they are crazy smart on there.
  • [13:09:23] * Tartarus (trini@pixelshelf.com) Quit (Excess Flood)
  • [13:09:51] * Tartarus (trini@46.21.157.24) has joined #beagle
  • [13:11:13] <jkridner_> USB
  • [13:11:24] * DevBot (~supybot@2001:6f8:12e0::7) Quit (Remote host closed the connection)
  • [13:11:33] * DevBot (~supybot@2001:6f8:12e0::7) has joined #beagle
  • [13:12:30] <koen> jkridner_: AFAICT no patches were ever posted publically
  • [13:12:58] <jkridner_> k
  • [13:12:59] <koen> jkridner_: and pointing to patches against 3.2.0.....
  • [13:14:21] <koen> jkridner_: FWIW 'disable DMA' is the only selectable option in that menu
  • [13:14:30] <jkridner_> k
  • [13:14:30] <koen> so it's not really an option at all
  • [13:14:49] <jkridner_> Just making sure no patches were posted that you brought in. thanks.
  • [13:15:08] <koen> I have kishons patches + panto fixup
  • [13:16:53] <koen> kishon wasn't aware that am335x existed since he was only looking at platforms with boardfiles :)
  • [13:17:21] <mdp> lol
  • [13:17:27] <av500> lol
  • [13:17:34] <mdp> koen, ok, so that's a bit of a stretch of the situation..but... ;)
  • [13:17:54] <koen> that's how I interpreted it :)
  • [13:18:13] <av500> what puzzles me is, why all the effort to get TI SoC to mainline when TI is stopping it all?
  • [13:18:23] <bradfa> av500, the rumorz!
  • [13:18:27] <mdp> av500, exactly! I can't figure it out either
  • [13:18:30] <koen> he does know about it now, but his communication with afzal is high latency
  • [13:18:33] <av500> inertia
  • [13:18:50] <koen> and full with WTFs like people not knowing how to apply 6 patches and asking for a tree
  • [13:19:11] <koen> sweet, replacement probes arrived for my scope
  • [13:19:20] * koen heads to the lab
  • [13:20:14] <av500> what did you do to them?
  • [13:20:17] <mdp> av500, a clown car, hurtling down the road at X speed loses force Y....
  • [13:20:22] <panto> back
  • [13:20:27] <av500> front
  • [13:21:17] <mru> top
  • [13:21:31] <mdp> koen, perhaps they are on opposite ends of the globe and the IP pigeons are running slow.
  • [13:21:51] <mdp> bottom
  • [13:22:05] <panto> up,down,up,down,left,left,right,a,a,b,b
  • [13:23:14] <av500> IDDQD
  • [13:23:41] <panto> bonus 1up
  • [13:23:50] <mru> LIM
  • [13:24:54] <jacekowski> IDKFA
  • [13:26:47] <bradfa> panto, up up down down left right left right b a b a select start (2 player ftw!)
  • [13:28:32] <mdp> ok, thanks, personal assistant just claimed there there's no work going on at work.
  • [13:28:52] <bradfa> mdp, can netflix help here?
  • [13:29:11] <av500> or a local folder
  • [13:29:15] <mdp> "lots of laughing and gaming references, is it coffee break?" ;)
  • [13:29:32] <mdp> bradfa, netflix..like opium
  • [13:30:20] <av500> never understimate the bandwith of a local folder full of ..... movies
  • [13:31:33] <bradfa> mdp, personal assistant is on irc?
  • [13:31:48] <mdp> shoulder looking
  • [13:31:55] * av500 blushes
  • [13:31:57] <mdp> bradfa, oh plz no
  • [13:32:15] * av500 waves
  • [13:32:25] <bradfa> mdp, you'll be happy to hear my excitement about plows arriving was short lived, they drove around parking lot once with plows up and then left...
  • [13:32:32] <mdp> ok, she says, "hi" and leaving us to our "work"
  • [13:32:42] <av500> hard work
  • [13:32:45] <mdp> indeed
  • [13:32:49] <av500> we toil away here endlessly
  • [13:32:52] <bradfa> we do!
  • [13:32:57] <mdp> perilous toiling!
  • [13:33:00] * av500 just fixed an ariane-5 bug
  • [13:33:06] <av500> leftover code from 2ys ago
  • [13:37:47] <panto> av500, those are nice
  • [13:38:00] <mdp> do you warm up leftover code before using it?
  • [13:38:14] <av500> its being kept warm all the time
  • [13:38:22] <av500> like italian pasta sauce pot
  • [13:38:27] <mdp> hold and cold running codez
  • [13:38:59] <av500> you just add more tomatoes over time
  • [13:39:04] <av500> and other stuff
  • [13:40:38] <mdp> mmm...you made me think of the .mx equivalent..the giant mole pot
  • [13:41:20] <mdp> ahh, yes, toiling
  • [13:50:16] <koen> Jacmet: am3358 at 1GHz with HDMI transmitter active: less than 500mA
  • [13:50:36] <koen> Jacmet: my PSU only has 0.1A granularity and it says 0.4A @ 5V
  • [13:50:56] <mru> koen: what is the PRU clock?
  • [13:51:02] <koen> doing 'cpufreq-set -g ondemand' drops it to 0.3A
  • [13:51:11] <koen> mru: I have no idea
  • [13:51:34] <mdp> mru, 200MHz
  • [13:51:34] * mrcan (~mrcan@unaffiliated/mrcan) has joined #beagle
  • [13:51:34] * mrcan (~mrcan@unaffiliated/mrcan) has joined #beagleboard
  • [13:51:34] * mrcan (~mrcan@unaffiliated/mrcan) has joined #beaglebone
  • [13:52:26] <mru> same as arm@720?
  • [13:53:42] <mru> koen: btw, still in memphis
  • [13:54:22] <koen> mru: ok, my parcel arrived this morning, but panto's is scheduled for next week
  • [13:54:36] <koen> so I guess yours is scheduled for the 29th as well?
  • [13:54:43] <mru> mine says 28th
  • [13:54:50] <panto> mine is 29th
  • [13:55:22] * mru hopes it's declared as something customs-friendly
  • [13:57:12] * jvcleave_ (~jvcleave@WS1-DSL-208-102-254-80.fuse.net) has joined #beagle
  • [13:57:52] * jvcleave (~jvcleave@WS1-DSL-208-102-254-80.fuse.net) Quit (Ping timeout: 256 seconds)
  • [13:57:52] * jvcleave_ is now known as jvcleave
  • [13:58:35] * nashpa (~nashpa@dliviu.plus.com) Quit (Ping timeout: 255 seconds)
  • [13:58:42] * arcanescu (925706ef@gateway/web/freenode/ip.146.87.6.239) has joined #beagle
  • [13:59:04] <panto> mru, guns from texas?
  • [14:01:58] * gustavoz (~gustavoz@host45.190-30-205.telecom.net.ar) Quit (Quit: Leaving)
  • [14:04:26] <jkridner_> koen: does that mean we'll get rid of the USB clock limiter?
  • [14:04:27] <av500> mine is in Memphis too
  • [14:04:40] <av500> and 28th
  • [14:06:34] * yegorich (3e911ef2@gateway/web/freenode/ip.62.145.30.242) has joined #beagle
  • [14:06:35] * rsalveti (~rsalveti@unaffiliated/rsalveti) has joined #beagle
  • [14:15:22] <koen> jkridner_: which one do you mean, the 275MHz or the 720MHz one?
  • [14:15:33] <jkridner_> the 500MHz one on start-up.
  • [14:15:37] <jkridner_> I guess it is gone already?
  • [14:15:39] <koen> yes
  • [14:15:50] <koen> that's why the bone-whites fail on usb power
  • [14:16:09] <koen> hrm, the servos take ~4A
  • [14:16:16] <koen> and I haven't connected all of them yet
  • [14:16:28] <koen> this 3A wallwart is not going to cut it for bone + servos
  • [14:17:21] <bradfa> KotH, I got cadstar zuken pricing, one sec on phone with sales guy
  • [14:18:39] <bradfa> KotH, http://algozen.com/CADSTAR_BUNDLES.htm <- packages
  • [14:21:30] <av500> http://www.cnx-software.com/2013/01/24/always-innovating-mecam-is-a-49-voice-controlled-nanocopter-camera/
  • [14:23:15] <jackmitchell> Always Innovating were the ones that were doing the tablet/keyboard thing years ahead of it's time
  • [14:23:21] <jackmitchell> nice to see they're still playing with
  • [14:23:30] <jackmitchell> things, but I wonder where they get the money from?
  • [14:24:12] <bradfa> KotH, lite $1888, basic $5257, pro $9257, ex $14257 (all prices include 1 year maint, extend at 15% of purchase price per year after that)
  • [14:24:16] * thurbad (~natesewel@cpe-70-113-204-247.austin.res.rr.com) Quit (Quit: thurbad)
  • [14:24:30] <bradfa> KotH, those prices for 1 seat, multi seat gets quotes
  • [14:24:34] <av500> haha: https://github.com/search?p=&q=%22id_rsa%22&ref=searchresults&type=Code
  • [14:25:46] <bradfa> KotH, license is node locked to MAC address
  • [14:25:59] <bradfa> they do offer 30 day full trial though
  • [14:26:14] <bradfa> pricing seems halfway between altium and PADS/orcad
  • [14:26:25] <mru> and nothing is easier than faking the system time
  • [14:26:26] <bradfa> the lite is eagle kind of money, though
  • [14:26:38] <bradfa> mru, nor mac addresses
  • [14:27:25] <mru> I have a nice little .so that intercepts most libc calls returning timestamps
  • [14:27:34] <mru> and applies an offset to them
  • [14:27:49] <bradfa> +1
  • [14:28:52] <mru> some apps stat random files looking for times after the expiry date
  • [14:29:01] <mru> and also trip on "future" times
  • [14:29:45] <av500> maybe an RTC over I2C over USB can help here
  • [14:30:09] <av500> and a kernel command line option apply_rtc_offset :)
  • [14:30:40] <mru> if you're willing to change the time globally, no tricks are needed
  • [14:30:44] <mru> just change the system time
  • [14:30:47] <mru> and disable ntp
  • [14:30:49] <yegorich> Hi! Are there any plans to include am335x-pm-firmware.bin into linux-firmware repo?
  • [14:31:02] <mru> faking it for a single process is a little harder
  • [14:32:03] <mru> sometimes patching the app to bypass the check is the simplest way
  • [14:32:32] <jackmitchell> koen, mdp, panto: I'm getting kernel panics due to the network stack on koens latest tree
  • [14:32:52] <jackmitchell> is this something anyone is aware of or should I speak to someone with some tracebacks?
  • [14:32:52] <mru> or simply patching the expiry date
  • [14:32:58] <mru> as in the case of that ibm compiler
  • [14:33:14] <koen> jackmitchell: you might need to disable NAPI
  • [14:33:47] <jackmitchell> NAPI?
  • [14:34:14] <koen> some fancy networking thing
  • [14:34:19] <koen> jackmitchell: have a look at https://github.com/pantoniou/linux-bbxm/commit/1552831f45afb45e6931764a225d9cb7e1ca3816
  • [14:34:36] <panto> jackmitchell, the cpsw driver is kinda b0rked
  • [14:35:02] <mdp> I meant to ask, but does the author/maintainer know yet?
  • [14:35:10] <panto> mdp, no idea
  • [14:35:38] <mdp> ok, so this hasn't been reported on the normal lists or directly?
  • [14:36:08] <panto> mdp, no
  • [14:36:46] <panto> I don't know if mentioning to people that you have to follow the TRM's method on acking an interrupt is nice on a mailing list
  • [14:37:11] <panto> and that the only way the original version worked was that the silicon was buggy
  • [14:37:40] <mdp> panto, um, ok
  • [14:37:49] <mdp> I'm not sure how to respond to that
  • [14:37:56] <mdp> "nice"?
  • [14:38:03] <panto> heh
  • [14:38:12] <koen> why do I get the feeling I'm supposed to explain to PSP what they did in their own kernel?
  • [14:38:27] <mdp> seriously, kinda confused as to how this is confused with some notion of being nice
  • [14:38:28] <panto> I can send the patch to the lkml/linux-omap lists
  • [14:38:36] * Openfree (~Openfree@120.204.176.65) has joined #beagle
  • [14:38:38] <mdp> either it's right or wrong in this type of thing
  • [14:38:50] <mdp> there's no semantics involved...phase of the moon..etc.
  • [14:39:14] <mdp> thx, cc the author or whoever submitted
  • [14:39:29] <mdp> I have nfc who owns it
  • [14:39:51] <panto> me neither
  • [14:40:09] <mdp> sure, since you worked on it, you have the git log in front of you
  • [14:40:34] <panto> "Mugunthan V N <mugunthanvnm@ti.com>"
  • [14:40:46] <mdp> it works sorta like google from my POV
  • [14:41:06] <mdp> well, that clears it up
  • [14:41:12] <mdp> ;)
  • [14:41:24] <panto> and earlier commits by "Richard Cochran <richardcochran@gmail.com>"
  • [14:41:30] * Hoolxi (~Openfree@117.144.142.99) Quit (Ping timeout: 264 seconds)
  • [14:41:55] <mdp> yeah, there was a thread where he extracted some broken commits from a WIP tree and submitted them upstream
  • [14:42:10] <mdp> I recall seeing that on lomap
  • [14:43:17] * GPSFan (~kenm@64.92.145.112) has joined #beagle
  • [14:43:32] <av500> lol: http://zigg.be/noisy
  • [14:45:01] <panto> mdp, btw, looks like there's smart switch driver support in mainline now
  • [14:45:15] <panto> take a look in drivers/net/dsa
  • [14:46:04] <panto> perhaps someone should look into getting cspw supported
  • [14:46:58] <av500> what was cspw again?
  • [14:47:16] * thurbad (~natesewel@64.132.24.36) has joined #beagle
  • [14:47:16] <mdp> panto, perhaps
  • [14:51:44] * falstaff (~quassel@62-12-225-213.pool.cyberlink.ch) has joined #beagle
  • [14:52:05] <jackmitchell> koen: disabling NAPI seemed to do the trick, thanks
  • [14:52:17] * falstaff_ (~quassel@62-12-227-163.pool.cyberlink.ch) Quit (Ping timeout: 248 seconds)
  • [14:52:42] <panto> jackmitchell, I noticed that too
  • [14:53:09] <jackmitchell> panto: yes, it was stolen from your WIP commit
  • [14:53:10] <panto> I guess the locking is all messed up for the NAPI case
  • [14:53:30] <jackmitchell> I assume so, it was locking that was causing me problems too
  • [14:53:39] <jackmitchell> nmap triggered it almost immediatly
  • [14:53:55] <koen> jackmitchell: ok, I'll add a patch for that
  • [14:54:15] <panto> IMO since the h/w support coalescing NAPI is a bit redundant
  • [14:54:24] <panto> but ofcourse it doesn't support it in PG1.0 silicon
  • [14:57:49] * emeb_mac (~ericb@ip72-201-78-226.ph.ph.cox.net) has joined #beagle
  • [15:10:43] * Openfree (~Openfree@120.204.176.65) Quit (Remote host closed the connection)
  • [15:20:04] * bzb (~bzb@69-196-189-45.dsl.teksavvy.com) Quit (Quit: Leaving)
  • [15:30:11] * fusion94 (~fusion94@pdpc/supporter/student/fusion94) has joined #beagle
  • [15:31:14] <jsabeaudry> koen, huh? is that really a problem with my patch?
  • [15:32:33] * drgalaxy (4506ac52@gateway/web/freenode/ip.69.6.172.82) Quit (Ping timeout: 245 seconds)
  • [15:35:22] * NishanthMenon (~nmenon@192.91.66.186) has joined #beagle
  • [15:39:39] <koen> jsabeaudry: no, it's problem with musb
  • [15:39:45] <Jacmet> panto: the dsa stuff is pretty limited
  • [15:39:53] <koen> jsabeaudry: it doesn't even reach the point that your patch fixes
  • [15:40:22] <Jacmet> panto: E.G. there's no link to the vlan/bridge infrastructure in the kernel
  • [15:40:32] <panto> Jacmet, it's still a place to start
  • [15:40:36] <Jacmet> panto: sure
  • [15:40:48] <panto> that doing it totally proprietary
  • [15:40:50] <panto> *than
  • [15:41:12] <Jacmet> panto: dsa pretty much halted when Lennert left Marvell
  • [15:41:28] <panto> figures
  • [15:41:30] * piezo (~piezo@pdpc/supporter/active/piezo) Quit (Ping timeout: 264 seconds)
  • [15:43:50] <yates> where is the format of the EEPROM data defining the pinmuxing defined?
  • [15:43:56] <yates> this looks close, but doesn't define what comes after the vendor and device IDs: http://elinux.org/BeagleBoardPinMux#EEPROM_content
  • [15:46:56] <yates> also, the information on that page on the SPI Multiplexor is wrong: "Interfaces to BeagleboardxM expansion connector and utilizes SPI channel 3 chip select 0." The bbxm rev C.1.0 schematic lists SPI channel 2 going to that connector.
  • [15:49:31] <panto> yates, pay not much attention to the pinmuxing in the eeprom of the capes
  • [15:49:51] <panto> afaikt it's mostly for bootloader use
  • [15:50:11] <panto> linux doesn't use it at all
  • [15:54:55] * prpplague (~danders@192.91.66.186) has joined #beagle
  • [15:57:08] * piezo (~piezo@pdpc/supporter/active/piezo) has joined #beagle
  • [16:05:59] <mdp> panto, I updated the edma binding and codez for #dma-cells = <2> so the client device can specific a queue
  • [16:06:00] * davest (~Adium@134.134.137.71) has joined #beagle
  • [16:06:19] <mdp> panto, useful for my updated asoc patches in the short-term
  • [16:06:23] * florian (~fuchs@Maemo/community/contributor/florian) Quit (Remote host closed the connection)
  • [16:06:32] <panto> I see
  • [16:06:59] <mdp> long-term..dmaengine has to also support that on a channel request
  • [16:08:17] <mdp> that was the intention of cells>1 anyway in the generic binding
  • [16:08:24] <mdp> s/binding/dma binding/
  • [16:14:57] * yates (~user@nc-71-54-138-0.dhcp.embarqhsd.net) Quit (Ping timeout: 248 seconds)
  • [16:16:48] * emeb_mac (~ericb@ip72-201-78-226.ph.ph.cox.net) Quit (Quit: emeb_mac)
  • [16:21:11] * emeb (~ericb@ip72-201-78-226.ph.ph.cox.net) has joined #beagle
  • [16:21:23] * kkeller (~Ken_Kelle@174-17-17-245.phnx.qwest.net) has joined #beagle
  • [16:23:37] * mrcan (~mrcan@unaffiliated/mrcan) Quit (Quit: Leaving)
  • [16:25:20] <jsabeaudry> Recommendations for the best 3.2 tree for beaglebone?
  • [16:25:23] * mrcan (~mrcan@unaffiliated/mrcan) has joined #beagle
  • [16:25:23] * mrcan (~mrcan@unaffiliated/mrcan) has joined #beagleboard
  • [16:25:23] * mrcan (~mrcan@unaffiliated/mrcan) has joined #beaglebone
  • [16:25:28] * mrcan_ (~mrcan@unaffiliated/mrcan) has joined #beagle
  • [16:25:28] * mrcan_ (~mrcan@unaffiliated/mrcan) has joined #beagleboard
  • [16:25:28] * mrcan_ (~mrcan@unaffiliated/mrcan) has joined #beaglebone
  • [16:25:29] * mrcan_ (~mrcan@unaffiliated/mrcan) Quit (Client Quit)
  • [16:26:22] <av500> device tree
  • [16:26:54] <jsabeaudry> kernel
  • [16:26:59] * ottoman (9960ab46@gateway/web/freenode/ip.153.96.171.70) has joined #beagle
  • [16:27:04] <ottoman> helloworld.
  • [16:27:17] <av500> .?
  • [16:27:28] <jsabeaudry> linux-omap, koen's last 3.2, beagleboard/kernel, other?
  • [16:27:30] <mru> av500: is that a regexp?
  • [16:27:47] <koen> jsabeaudry: beagleboard/kernel and 'my' 3.2 are the same
  • [16:27:59] <ottoman> i would like to connect a beagleboard to ARM DS-5. so far, the debug configuration tool is able to identify my beagleboard when it is connected, but in DS-5 it is unable to connect to the beagleboard
  • [16:28:02] <koen> jsabeaudry: one is just a git tree resulting from running the patch.sh script
  • [16:28:08] <ottoman> anyone have the ARM RVI debugger working?
  • [16:28:27] <mru> I'm sure _someone_ does
  • [16:28:42] <mru> I'm also fairly sure it's not you
  • [16:29:17] <ottoman> alright.
  • [16:35:50] * W1N9Zr0 (~W1N9Zr0@24.212.193.98) has joined #beagle
  • [16:38:07] * smplman (~speery@cn-sfo1-natout.cnet.com) has joined #beagle
  • [16:42:08] * DevBot (~supybot@2001:6f8:12e0::7) Quit (Remote host closed the connection)
  • [16:42:16] * DevBot (~supybot@2001:6f8:12e0::7) has joined #beagle
  • [16:43:01] * W1N9Zr0 (~W1N9Zr0@24.212.193.98) Quit (Remote host closed the connection)
  • [16:44:23] * W1N9Zr0 (~W1N9Zr0@24.212.193.98) has joined #beagle
  • [16:48:23] * yegorich (3e911ef2@gateway/web/freenode/ip.62.145.30.242) Quit (Ping timeout: 245 seconds)
  • [17:00:45] * XorA|gone is now known as XorA
  • [17:09:09] <KotH> bradfa: thanks!
  • [17:09:47] <bradfa> KotH, welcome
  • [17:09:51] <KotH> bradfa: the prices seem ok..still quite expensive, but ok
  • [17:09:53] <bradfa> not quite "low prices"
  • [17:10:39] <KotH> bradfa: you didnt ask about the cr-5000/8000?
  • [17:10:47] <bradfa> no, sorry
  • [17:10:56] * ew (cd97720c@gateway/web/freenode/ip.205.151.114.12) has joined #beagle
  • [17:11:27] <bradfa> didn't notice them...
  • [17:11:31] * bradfa needs to read better
  • [17:11:32] <KotH> :-)
  • [17:11:53] <KotH> bradfa: the video with the 3d stuff from yesterday was the cr-8000
  • [17:11:57] <bradfa> ah, ok
  • [17:12:49] <KotH> i wouldnt be surprised if that stuff is twice the price
  • [17:12:56] <bradfa> from the looks, you're probably right
  • [17:14:26] <bradfa> hmmm, not good -> kernel:[183985.264174] journal commit I/O error
  • [17:14:42] * KotH hands bradfa a new hd
  • [17:14:50] * bradfa scrambles to do backup!
  • [17:15:04] * jpirko (~jirka@ip-94-112-98-141.net.upcbroadband.cz) Quit (Quit: Leaving)
  • [17:15:29] * KotH wonders if zuken would give out cheap version of their software for hobbists
  • [17:15:44] <bradfa> KotH, free 30 day trial
  • [17:16:09] <KotH> bradfa: yeah... and then crack it to extend that 30day...
  • [17:16:22] <bradfa> KotH, play mru's "change the date" game :)
  • [17:16:42] * bradfa 's backup now in progress
  • [17:16:48] * bradfa crosses fingers that ssd isn't dead...
  • [17:17:03] <bradfa> or dying
  • [17:17:19] <bradfa> maybe a good excuse to pawn the laptop onto someone else and buy a real computer
  • [17:17:31] <XorA> :-D
  • [17:17:54] <bradfa> I have my eye on an Intel Xeon system
  • [17:18:17] <KotH> for a laptop?
  • [17:18:19] <KotH> ;)
  • [17:18:27] <bradfa> KotH, if only!
  • [17:18:33] <bradfa> I'd like something with real serial ports
  • [17:18:36] <bradfa> I'm sick of USB
  • [17:18:41] <KotH> hehe
  • [17:18:46] <KotH> these are hard to get these days
  • [17:18:50] <bradfa> USB is OK for keybaords and mice, everything else should use a real bus
  • [17:18:57] <bradfa> like serial
  • [17:19:01] * XorA has real hard seriel ports, every second kernel release 8250 driver is broken :-(
  • [17:19:01] <ynezz> sure
  • [17:19:02] <bradfa> or PCI, I guess
  • [17:19:06] <KotH> bradfa: and just to make you envious: my home desktop is an dual xeon system :)
  • [17:19:19] * bradfa sneaks over to KotH's house and steals computer
  • [17:19:28] <KotH> bradfa: you probably dont want to
  • [17:19:30] * bradfa 's home desktop is a 7 year old dual Opteron
  • [17:19:36] <KotH> it's a 7y old HP ML110
  • [17:19:43] <bradfa> so we're in the same age group!
  • [17:19:47] <KotH> juup
  • [17:19:48] <crashovrd> oh how cute, u have x86 systems
  • [17:19:53] <KotH> lol
  • [17:20:06] <bradfa> I've got a 400GBx4 RAID5 on PCI-X
  • [17:20:11] <bradfa> it was fast, 7 years ago
  • [17:20:13] <KotH> bradfa: the oly good thing about this box is, that it has 8gb of ram
  • [17:20:22] <bradfa> KotH, I've got 2 at home, 8 in the lappy
  • [17:20:25] <KotH> bradfa: otherwise i would have thrown it out already
  • [17:20:29] <bradfa> Next desktop won't have less than 32
  • [17:20:39] <bradfa> builds go in tmpfs, where they belong
  • [17:21:02] <ynezz> in that time you would need like 64GB
  • [17:21:03] <KotH> bradfa: same here, my laptop has a i7 with 8gb mem
  • [17:21:12] <ynezz> systemd is growing...
  • [17:21:19] <bradfa> ynezz, systemd, you're funny :)
  • [17:22:09] <bradfa> Dell has some decent Xeon systems for reasonable prices these days
  • [17:22:21] <bradfa> I'm uncertain if building my own box is worth it any more
  • [17:22:26] <bradfa> other than buying my own ram and ssds
  • [17:22:45] <ynezz> Dell is going bankrupt...
  • [17:23:04] <bradfa> ynezz, well, HP or Lenovo, then
  • [17:23:08] <crashovrd> and intel is exiting the motherboard biz
  • [17:23:17] <mdp> I heard amazon is buying all of them
  • [17:23:18] <bradfa> crashovrd, desktop motherobard biz
  • [17:23:19] <KotH> crashovrd: huh? what?
  • [17:23:21] <bradfa> not server / workstation
  • [17:23:32] <crashovrd> *desktop* motherboard biz
  • [17:23:37] <bradfa> KotH, in like 3 years intel says they're getting out of the desktop motherboard manufacturing biz
  • [17:23:48] <KotH> sounds strange
  • [17:23:52] <bradfa> they'll still make chipsets
  • [17:23:54] <KotH> took them agaes to get in...
  • [17:24:04] <bradfa> KotH, they have planety of time to change their minds
  • [17:24:05] <bradfa> :)
  • [17:24:11] <KotH> *g*
  • [17:24:48] <ynezz> well, there would be no desktop at that time
  • [17:25:08] <mdp> ahh, yes,,the ever-useful "3 year business plan"
  • [17:25:09] * ew (cd97720c@gateway/web/freenode/ip.205.151.114.12) has left #beagle
  • [17:25:09] <ynezz> you'll just put your car keys in docking station...
  • [17:25:11] <mdp> duh
  • [17:25:30] <bradfa> mdp, you'll be glad to know the plows came back and plowed one strip down the parking lot
  • [17:25:36] <bradfa> rest is still snow covered
  • [17:25:49] <bradfa> ynezz, more like put Credit Card in slot
  • [17:26:01] <mdp> bradfa, they are at the donut shop, most likely
  • [17:26:26] <ynezz> bradfa: CC with 64GB of RAM?
  • [17:26:36] <bradfa> smart cards!
  • [17:26:42] <KotH> that's comming!
  • [17:26:49] <bradfa> with "encryption"!
  • [17:26:56] <KotH> hehe
  • [17:27:20] <bradfa> encryption solves everything!
  • [17:27:48] <mdp> bradfa, I built a new machine recently and still found I preferred to select the exact mobo w/ slot config etc. I wanted rather than sifting through random dells
  • [17:28:27] <mdp> the level of effort to put the mobo/cpu in a case is hardly worth purchasing the wrong thing
  • [17:28:34] <bradfa> yeah
  • [17:28:39] <bradfa> true
  • [17:29:01] <mdp> I mean, they're going to have the wrong ram and ssd to start as you point out anyway
  • [17:29:13] <crashovrd> there was a time when i knew the exact part number and spec of everything in a system. now i could not even tell you what proc is in this one
  • [17:29:21] <crashovrd> its an intel something... something.. something
  • [17:29:37] <bradfa> yes, but I have found that if you buy high end stuff from Dell/HP, it's actually very well designed unlike quite a lot of the mobos that come by themselves
  • [17:29:37] <mdp> crashovrd: I'll forget soon
  • [17:30:15] * DevBot (~supybot@2001:6f8:12e0::7) Quit (Remote host closed the connection)
  • [17:30:21] <bradfa> and often Dell can make something high powered quiet, which takes a bit of effort on the DIY side unless you love reading PC review sites
  • [17:30:23] * DevBot (~supybot@2001:6f8:12e0::7) has joined #beagle
  • [17:30:50] <crashovrd> there is just no payoff anymore to building the ULTIMATE pc
  • [17:30:56] <crashovrd> there is only so fast you can run a web browser
  • [17:31:14] <mdp> sure, always exception features..depends on what you value
  • [17:31:19] <crashovrd> how fast do you need a wordprocessor to go?
  • [17:31:50] <KotH> crashovrd: blazingly fast!
  • [17:31:55] <bradfa> crashovrd, even faster!
  • [17:32:06] <crashovrd> i did find it amusing that Visual Studio 2010 and higher have *hardware* acceleration
  • [17:32:11] <crashovrd> for the GUI
  • [17:32:17] <mdp> bradfa: I built mine to land in the "sweet-spot" of pricing but 8 cores, 16gb ram, big ssd for my build needs
  • [17:32:51] <mdp> bradfa, and I have a particular taste for a few old pci slots and a real 8250 too
  • [17:33:07] <KotH> mdp: not a 16550?
  • [17:33:12] <bradfa> oh, don't get me wrong, what ever desktop I buy will have gobs of serial ports
  • [17:33:13] <mdp> :)
  • [17:33:19] <crashovrd> he's got a PC XT
  • [17:33:21] <crashovrd> :P
  • [17:33:22] <bradfa> I hate this usb crap
  • [17:33:23] <mdp> KotH: I don't believe in FIFOs!
  • [17:33:36] * KotH remembers the time, when mainboards put the type of their uart as a major feature
  • [17:33:56] <bradfa> KotH, to some of us, we still consider that a very important feature
  • [17:33:57] <bradfa> :)
  • [17:34:00] <mdp> bradfa, oh come now...don't take your frustration out on USB...it's completely innocent.
  • [17:34:28] <bradfa> gimme PS/2, mechanical keyboard, some serial ports, and OK maybe some firewire
  • [17:35:00] <crashovrd> anyone remember the Commodore 64 and its serial floppy drive? they were ahead of their time! (and loading from it was like watching paint dry)
  • [17:35:15] <crashovrd> who would have thought that all these years later we would be back to serial buses
  • [17:35:33] <mdp> crashovrd: yet we loved it...it was much better than loading from cassette.
  • [17:35:58] <mdp> then have your sister take the same cassette and record singing over it..wtf?
  • [17:36:03] <mdp> boo
  • [17:36:25] <KotH> bradfa: exsys still sells rs-232 cards for pci-e
  • [17:36:36] * thurbad (~natesewel@64.132.24.36) Quit (Read error: Connection reset by peer)
  • [17:36:41] * thurbad_ (~natesewel@64.132.24.36) has joined #beagle
  • [17:36:42] <KotH> bradfa: like the ex-44098, an 8port card :)
  • [17:36:48] * ka6sox is now known as ka6sox-away
  • [17:36:48] <bradfa> KotH, links?
  • [17:36:51] <crashovrd> oh! lets start a BBS
  • [17:36:54] <mdp> KotH: how can there be a market with all the awesome usb ones? ;)
  • [17:37:01] <KotH> bradfa: http://www.exsys-shop.ch/shop/product_info.php?info=p528_PCIe-8S-Seriell-RS-232-Karte--Oxford.html
  • [17:37:12] <KotH> bradfa: dunno whether there is an english site
  • [17:37:15] <mdp> crashovrd: see you on FidoNET
  • [17:37:24] <crashovrd> +++ATH
  • [17:37:29] <KotH> mdp: uhmm.. there seem to be enough crazy people like you around
  • [17:37:37] <bradfa> KotH, yes! nice find!
  • [17:37:45] <KotH> crashovrd: you forgot the pause between the +++ and the ATH :)
  • [17:37:48] <bradfa> don't even get me started on USB to serial converters
  • [17:37:53] <bradfa> there's 1 good kind, the rest suck
  • [17:37:56] <mdp> KotH: s/crazy people/people that need shit that works/
  • [17:38:09] <KotH> bradfa: exsys is your friend when it comes to strange adapter cards and systems
  • [17:38:10] <bradfa> hint: the good kind isn't made by ftdi
  • [17:38:21] <KotH> bradfa: i buy often their stuff. it's not the cheapest but it works very well
  • [17:38:35] <bradfa> KotH, but it eats USB bus
  • [17:38:52] <bradfa> if you have a few interrupt end points on the same bus with an FTDI, everybody gets pissed off
  • [17:39:00] <KotH> bradfa: what do you mean "eats usb"?
  • [17:39:12] <KotH> ah..
  • [17:39:14] <KotH> dont use ftdi
  • [17:39:24] <bradfa> KotH, they use quite a lot of USB bus bandwidth the way they get setup, at least on widnwos boxes
  • [17:39:35] <bradfa> makes running a Saele logic difficult
  • [17:39:38] <bradfa> it also eats bus
  • [17:39:47] * NulL (~bleh1@87.254.68.140) has joined #beagle
  • [17:39:49] <mdp> bradfa, btw, local company a friend used to work for: http://www.quatech.com/products/serialboards.php
  • [17:39:51] <KotH> bradfa: yeah
  • [17:40:09] <mdp> bradfa, same stuff, I've used it before..they also have some other cool quirky IO things ;)
  • [17:40:10] * NulL is now known as Guest13656
  • [17:40:12] <KotH> bradfa: friend tried an ftdi i2c usb dongle
  • [17:40:26] <KotH> bradfa: got horrified after he noticed that every bit requires an usb transaction
  • [17:40:31] <bradfa> http://www.exsys-shop.ch/shop/product_info.php?info=p297_PCIe-8S-Seriell-RS-232-Module.html
  • [17:40:55] <bradfa> I want that!
  • [17:41:05] * florian (~fuchs@Maemo/community/contributor/florian) has joined #beagle
  • [17:41:13] * bhthompson (bhthompson@nat/google/x-qfbfkkhpcuhzyepo) Quit (Quit: Leaving.)
  • [17:41:17] * AndrevS (~andrevs@wlan-229232.nbw.tue.nl) has joined #beagle
  • [17:41:21] <KotH> *g*
  • [17:42:36] <mdp> bradfa, don't you need a parallel port too?
  • [17:42:42] <bradfa> mdp, yes
  • [17:42:46] <bradfa> so I can bit twiddle
  • [17:43:12] <mdp> quatech has the expresscard versions too ;)
  • [17:43:34] <mdp> or rs-485?
  • [17:43:51] <bradfa> rs-485 less used around here
  • [17:44:03] <bradfa> I have expresscard gigabit ethernet in laptop
  • [17:44:04] <bradfa> it works OK
  • [17:44:07] <mdp> all the rage here
  • [17:44:07] <bradfa> marvel chipset
  • [17:44:50] <mdp> I used one of the twin rs-232 expresscard units on a past laptop
  • [17:45:25] <mdp> all this stuff works great when it's on a real bus, of course
  • [17:45:47] <bradfa> http://www.exsys-shop.ch/shop/product_info.php?info=p5_Expansion-Box-PCI-Express-Slot-zu-4-x-PCI-Slots.html
  • [17:45:49] <bradfa> want!
  • [17:45:52] * mythos (~mythos@unaffiliated/mythos) Quit (Read error: Operation timed out)
  • [17:45:55] <bradfa> and a tape drive
  • [17:46:19] <KotH> bradfa: didnt i say they have cool stuff :)
  • [17:46:21] <mdp> everybody needs that
  • [17:46:27] <bradfa> KotH, yes!
  • [17:46:45] <mdp> bradfa, why doesn't Dell bundle these features? ;)
  • [17:47:00] <bradfa> mdp, they are focused on the "enterprise cloud"
  • [17:47:01] <bradfa> or something
  • [17:47:18] <mdp> "Dell Inspiron PCIe/PCI expansion box bundle"
  • [17:47:21] * bradfa goes to meeting...
  • [17:47:34] <mdp> you had me at cloud
  • [17:47:45] * tema_ (~tema@95-55-116-156.dynamic.avangarddsl.ru) Quit (Ping timeout: 248 seconds)
  • [17:48:44] * ant_work (~ant@host6-80-static.42-85-b.business.telecomitalia.it) Quit (Quit: Leaving)
  • [17:49:40] <CareBear\> aw
  • [17:49:58] <CareBear\> everyone is in seventh heaven
  • [17:55:20] * ottoman (9960ab46@gateway/web/freenode/ip.153.96.171.70) Quit (Quit: Page closed)
  • [17:57:57] * bhthompson (bhthompson@nat/google/x-nxvrutdukecuqdjw) has joined #beagle
  • [17:58:37] * bhthompson (bhthompson@nat/google/x-nxvrutdukecuqdjw) Quit (Client Quit)
  • [18:00:23] * djlewis (~djelwis@adsl-65-64-30-13.dsl.ltrkar.swbell.net) has joined #beagle
  • [18:01:13] * fusion94 (~fusion94@pdpc/supporter/student/fusion94) Quit (Remote host closed the connection)
  • [18:01:30] * fusion94 (~fusion94@pdpc/supporter/student/fusion94) has joined #beagle
  • [18:02:04] <mrpackethead_> .
  • [18:02:25] * bhthompson (bhthompson@nat/google/x-elmbalfaoivjvljc) has joined #beagle
  • [18:02:28] <mdp> ..
  • [18:02:49] <mranostay> ...
  • [18:06:07] <mru> ....
  • [18:08:03] <emeb> .....
  • [18:08:26] * djlewis ......
  • [18:09:19] <mru> eish5<EILSEQ>
  • [18:12:03] * fusion94-work (~fusion94@c-67-188-100-107.hsd1.ca.comcast.net) has joined #beagle
  • [18:16:24] * fusion94 (~fusion94@pdpc/supporter/student/fusion94) Quit (Ping timeout: 264 seconds)
  • [18:19:17] <mdp> *board killer: http://www.gizmosphere.org/why-gizmo/
  • [18:19:32] * Wipster (~Wip@host81-137-80-202.in-addr.btopenworld.com) Quit (Ping timeout: 248 seconds)
  • [18:19:39] * woglinde (~henning@f052016073.adsl.alicedsl.de) has joined #beagle
  • [18:20:27] <mrpackethead_> mdp: whats it goign to kill
  • [18:20:50] <mdp> one must apply "killer" to all new board releases
  • [18:20:58] <mdp> I don't know what it could kill
  • [18:21:19] <crashovrd> if it has a heatsink, "you're doing it wrong!"
  • [18:21:25] <crashovrd> think of the children!
  • [18:21:42] <mdp> perhaps it's a child-killer then
  • [18:22:00] <crashovrd> its more x86 eco terrorism!
  • [18:22:59] <crashovrd> i got a laugh out of the Ouya dev kits.
  • [18:23:09] <crashovrd> its a tegra3 arm soc
  • [18:23:17] <crashovrd> with a HEATSINK!
  • [18:23:59] <mru> I'm reminded of a couple of STBs I worked with a few years ago
  • [18:24:05] <mru> both used the same bcm chip
  • [18:24:25] <mru> one (by thomson) had no heatsink, the other (by lg) had a massive one
  • [18:24:52] <mru> in the lg box the chip was hot enough to fry the breakfast bacon
  • [18:25:05] <mru> the thomson one wasn't even slightly warm
  • [18:25:17] <mru> and they ran the exact same software
  • [18:25:20] <KotH> mru: did you ever figure out what made the difference?
  • [18:25:37] <crashovrd> i would say its clock rate
  • [18:25:43] <mru> the lg board must have set some output pin high and shorted it to ground
  • [18:25:49] <mru> crashovrd: exactly the same
  • [18:26:04] <mru> the boxes were supposed to have the exact same specs
  • [18:26:12] <mru> directv multi-sourcing
  • [18:26:34] <crashovrd> maybe one used the evil vendor tree
  • [18:26:36] <florian> crashovrd: I decided not to like tegra when i first burned my fingers on a tegra at embedded world ;-)
  • [18:26:45] <mru> crashovrd: not running linux
  • [18:27:00] <KotH> mru: sounds like the soekris net5501 compared to any alix board: both have the same cpu, at same clock, but while the alix board doesnt get hot at all, the soekris runs at >70?C when being idle and the case open
  • [18:27:16] <mru> crashovrd: they ran exactly the same software
  • [18:27:39] <crashovrd> maybe one was fabbed with dirt
  • [18:27:42] <crashovrd> :)
  • [18:27:43] <mrpackethead_> even my 80W leds don't run hot
  • [18:28:12] <mranostay> 80W LEDS?
  • [18:28:17] <mrpackethead_> yup
  • [18:28:19] <mrpackethead_> 80W
  • [18:28:27] <crashovrd> they can see your house from space
  • [18:28:35] <mrpackethead_> cree makes them for street lights
  • [18:29:44] <mrpackethead_> but they do have a heat sink.
  • [18:30:09] <KotH> mrpackethead_: what's the efficiency of those leds?
  • [18:31:04] <mrpackethead_> its qutie high, jsut looking
  • [18:31:14] <KotH> must be
  • [18:31:16] <koen> 80W is the incandescant power usage
  • [18:31:26] <KotH> though, i thought that white leds have something around 80% or so
  • [18:31:35] <koen> so "80W led" means "as bright as 80W bulb, uses on 4W"
  • [18:31:41] <mrpackethead_> no.. its 80W of power
  • [18:32:08] * arcanescu (925706ef@gateway/web/freenode/ip.146.87.6.239) Quit (Ping timeout: 245 seconds)
  • [18:32:10] * tema_ (~tema@178-16-155-142.obit.ru) has joined #beagle
  • [18:32:35] * shoragan (~jlu@debian/developer/shoragan) Quit (Quit: Leaving)
  • [18:32:44] <mrpackethead_> cree web site is running like a dog
  • [18:34:20] <mrpackethead_> 122 lm/W
  • [18:34:58] <mrpackethead_> getting up to abotu 6000 lumens out of them
  • [18:35:05] <mranostay> mru: so Nikon or Canon?
  • [18:36:01] <mrpackethead_> geepers; thats like asking; Macos or Windows, Nike or rebok..
  • [18:36:40] <KotH> ubuntu! and adidas
  • [18:36:54] * arcanescu (925706ef@gateway/web/freenode/ip.146.87.6.239) has joined #beagle
  • [18:36:58] <mru> mranostay: huh?
  • [18:37:11] <mranostay> mru: camera choices
  • [18:37:24] <mru> I'm partial to canon
  • [18:37:37] <mru> but I hear nikon make some good stuff too
  • [18:38:05] <KotH> mranostay: choose wisely, as it is a choice for life... and probably for your children and grand children as well :)
  • [18:39:16] <koen> mru: Cree XM?
  • [18:39:24] <mru> koen: huh?
  • [18:39:36] <koen> cree uses similar names, coincidence
  • [18:45:02] * kiilo (~kiilo@46-126-77-178.dynamic.hispeed.ch) Quit (Quit: ciao)
  • [18:45:28] * arcanescu (925706ef@gateway/web/freenode/ip.146.87.6.239) Quit (Ping timeout: 245 seconds)
  • [18:46:56] <mru> koen: what's that got to do with me?
  • [18:47:46] <Crofton|work> mru, will you be at FOSDEM?
  • [18:47:56] <koen> ah
  • [18:48:05] <koen> s/mru/mrpackethead/
  • [18:48:54] * damir__ (~damir@cpe-212-85-175-204.cable.telemach.net) has joined #beagle
  • [18:54:38] * mrpackethead_ (~mrpacketh@118-93-95-178.dsl.dyn.ihug.co.nz) Quit (Remote host closed the connection)
  • [18:55:06] * mrpackethead_ (~mrpacketh@118-93-95-178.dsl.dyn.ihug.co.nz) has joined #beagle
  • [18:57:07] <jsabeaudry> How to instanciate virtual i2c busses from sysfs?
  • [18:59:18] * mrpackethead_ (~mrpacketh@118-93-95-178.dsl.dyn.ihug.co.nz) Quit (Ping timeout: 244 seconds)
  • [19:03:12] <KotH> .o0(sie m?ssen nur den nippel durch die lasche ziehn....)
  • [19:06:28] <woglinde> koth dont steal from us
  • [19:06:53] * slchen (~slchen@123-195-161-155.dynamic.kbronet.com.tw) has joined #beagle
  • [19:08:04] <KotH> woglinde: ?
  • [19:10:29] * mrpackethead_ (~mrpacketh@118-93-95-178.dsl.dyn.ihug.co.nz) has joined #beagle
  • [19:17:26] * slchen (~slchen@123-195-161-155.dynamic.kbronet.com.tw) Quit (Quit: slchen)
  • [19:20:11] <mrpackethead_> im looking at pin muxing
  • [19:20:23] <mrpackethead_> geepers its exciting.. not
  • [19:23:47] * NulL` (~bleh1@87.254.86.222) has joined #beagle
  • [19:25:50] * florian (~fuchs@Maemo/community/contributor/florian) Quit (Ping timeout: 276 seconds)
  • [19:27:00] * Guest13656 (~bleh1@87.254.68.140) Quit (Ping timeout: 276 seconds)
  • [19:29:56] * NulL` (~bleh1@87.254.86.222) Quit (Ping timeout: 248 seconds)
  • [19:29:58] * rgentner (~Geminizer@sledge.ccr.buffalo.edu) Quit (Quit: Leaving...)
  • [19:32:10] * NulL (~bleh1@217.28.12.22) has joined #beagle
  • [19:32:34] * NulL is now known as Guest81526
  • [19:33:40] * mythos (~mythos@unaffiliated/mythos) has joined #beagle
  • [19:34:08] <prpplague> koen: hey, you know if the wifi caps are done?
  • [19:38:05] * slchen (~slchen@123-195-161-155.dynamic.kbronet.com.tw) has joined #beagle
  • [19:39:21] <mranostay> wifi caps?
  • [19:40:39] * Geminizer (~Geminizer@sledge.ccr.buffalo.edu) has joined #beagleboard
  • [19:40:39] * Geminizer (~Geminizer@sledge.ccr.buffalo.edu) has joined #beagle
  • [19:41:06] <mrpackethead_> Somethign you put on a trolls head to connect them when you move?
  • [19:41:29] <ds2> hmmm
  • [19:42:33] * yates (~user@nc-71-54-138-0.dhcp.embarqhsd.net) has joined #beagle
  • [19:43:59] * arcanescu_ (925706ef@gateway/web/freenode/ip.146.87.6.239) has joined #beagle
  • [19:45:01] * arcanescu_ is now known as arcanescu
  • [19:46:18] * florian (~fuchs@Maemo/community/contributor/florian) has joined #beagle
  • [19:47:47] * AndrevS (~andrevs@wlan-229232.nbw.tue.nl) Quit (Ping timeout: 255 seconds)
  • [19:50:01] * slchen (~slchen@123-195-161-155.dynamic.kbronet.com.tw) Quit (Ping timeout: 246 seconds)
  • [19:50:34] <mrpackethead_> is there any concept of remappable pin functions in teh AM3559
  • [19:50:50] <mrpackethead_> i know you can choose between the functions of the pins
  • [19:51:32] <_av500_> sure
  • [19:51:50] <_av500_> the chip lets you remap pins any time
  • [19:52:04] * fusion94-work is now known as fusion94
  • [19:52:05] * fusion94 (~fusion94@c-67-188-100-107.hsd1.ca.comcast.net) Quit (Changing host)
  • [19:52:05] * fusion94 (~fusion94@pdpc/supporter/student/fusion94) has joined #beagle
  • [19:52:25] <mrpackethead_> but only the functions that are on that pin.
  • [19:53:00] <mrpackethead_> GPIO2_28 for example appears on pin G15
  • [19:53:09] * KeatonT (~textual@unaffiliated/keatont) has joined #beagle
  • [19:53:15] <mrpackethead_> i cna't remap that somehow to F18
  • [19:53:22] <mrpackethead_> GPIO is not a great example
  • [19:54:19] <mrpackethead_> PRUETH1_RXCLK appears on U16..
  • [19:54:28] <mrpackethead_> U16 is Not connected on the beaglebone.
  • [19:54:45] <mrpackethead_> some chipsets can map betweeen pins
  • [19:55:44] <mdp> the full capability of the pinmux is detailed in the datasheet..that's it.
  • [19:56:16] <mrpackethead_> yup.. thats the way that i read it
  • [19:56:29] <mrpackethead_> i just wanted to make sure that i had'nt missed any magic
  • [19:57:02] <mdp> you have not missed anything
  • [19:57:26] <mrpackethead_> there are five pins i can not access
  • [19:57:27] <mrpackethead_> :-(
  • [19:57:55] * bzb (~bzb@69.196.189.45) has joined #beagle
  • [19:58:14] <mrpackethead_> jkridner_: are you about
  • [19:58:43] <mdp> yeah, that's a common step in the design-in process...either the part can meet the customer's requirements...or not. it can't meet everybody's reqmts
  • [19:58:51] <mrpackethead_> absolteuly.
  • [19:59:13] <mrpackethead_> its not the end of the world though mdp
  • [19:59:20] <mrpackethead_> there are ways and means
  • [19:59:21] <mdp> e.g. for one project, I need 8 uarts..and it totally fails me
  • [19:59:22] <mrpackethead_> :-)
  • [19:59:22] <mdp> ;)
  • [19:59:48] <mdp> mrpackethead_: right, it's just another arm part, the world will not miss one arm part
  • [19:59:55] <mrpackethead_> use the UARTS and the PRU's? ( some soft UARTS )
  • [20:00:21] <mdp> yeah, it is an option
  • [20:00:32] <mrpackethead_> there you go, its not failed you.
  • [20:00:53] <mrpackethead_> problem shared, problem havlved..
  • [20:00:54] <mrpackethead_> lol.
  • [20:00:57] <mdp> unless you are you the pru for other stuff so you can't just use the COTS soft uart f/w for PRU
  • [20:01:08] <mdp> s/you the/using the/
  • [20:01:14] <mrpackethead_> yup.
  • [20:01:25] <mdp> anyway, always tradeoffs ;)
  • [20:01:37] * dv_ (~quassel@chello080108009040.14.11.vie.surfer.at) Quit (Read error: Connection reset by peer)
  • [20:01:43] <mrpackethead_> I want to implement Profinet and Ethercat under Linux
  • [20:02:03] <mrpackethead_> The TI folks have got the 'ICE' board
  • [20:02:42] * dv_ (~quassel@chello080108009040.14.11.vie.surfer.at) has joined #beagle
  • [20:02:45] <mrpackethead_> its got Ethercat/Profinet.. but it runs their RTOS system
  • [20:02:54] <mrpackethead_> getting all the other code to run under that would be a nightmare
  • [20:03:21] <mrpackethead_> moving the ethercat to linux is much less work.
  • [20:03:32] <mrpackethead_> however you need to use the PRU_MII ports
  • [20:03:35] <ds2> you could always slap on 8 TUSB chips ;)
  • [20:04:35] <mrpackethead_> sadly, 5 of the 28 required pins are not on the headers
  • [20:04:50] * AndrevS (~andrevs@2001:610:1108:5011:225:b3ff:fec0:41e1) has joined #beagle
  • [20:04:50] <mrpackethead_> but i am not giving up
  • [20:06:04] * calculu5 is now known as calculus
  • [20:06:53] * Splats (~splats@c-98-207-35-62.hsd1.ca.comcast.net) has joined #beagle
  • [20:06:53] * Splats (~splats@c-98-207-35-62.hsd1.ca.comcast.net) Quit (Changing host)
  • [20:06:53] * Splats (~splats@unaffiliated/splats) has joined #beagle
  • [20:07:13] <mdp> ds2, ok, now stop that! ;)
  • [20:08:08] <mdp> mrpackethead_: what headers..are you talking about bone now?
  • [20:08:18] <mrpackethead_> yes, bone.
  • [20:09:10] <mrpackethead_> there is enough pins to implemnet a single port
  • [20:09:16] <mdp> spin your own derivative?
  • [20:09:16] * AndrevS (~andrevs@2001:610:1108:5011:225:b3ff:fec0:41e1) Quit (Client Quit)
  • [20:09:27] <mrpackethead_> i'm thinking about that
  • [20:09:48] <mrpackethead_> the easiest way is simply to add another layer to the pcb
  • [20:12:10] * krajo1 (~krajo1@ip4-83-240-125-22.cust.nbox.cz) has joined #beagle
  • [20:13:51] <mrpackethead_> jkridner_ suggested yesterday that it may be possible in a future revsiosn to get to the pins.
  • [20:14:01] <mrpackethead_> they have joined some pins togehter already.
  • [20:14:17] <jkridner_> about
  • [20:14:22] <mrpackethead_> hello.
  • [20:14:46] <mrpackethead_> jkridner_: just following though on our dicsusion yesterday about Pin avaialblily
  • [20:14:57] <djlewis> back in the day, on beaglebone, we asked for the camera pins to be revealed and later they were :)
  • [20:15:27] <mrpackethead_> i worked on establihsing which additinal pins i needed to see
  • [20:15:30] <djlewis> beagleboard
  • [20:15:37] <mrpackethead_> and theres 5
  • [20:15:41] <jkridner_> Gerald will likely say no, but if you get the list of balls, they are unused and list the pins to which you'd like to connect them on a very clear email sent to the mailing list, Gerald might decide it is easy enough to update it on a future spin.
  • [20:16:21] <ds2> hahahahah
  • [20:16:23] * mranostay reports jkridner_ to HR
  • [20:16:31] <mdp> ds2, I misread that too ;)
  • [20:16:40] <jkridner_> lol
  • [20:16:47] * KeatonT (~textual@unaffiliated/keatont) Quit (Quit: Computer has gone to sleep.)
  • [20:17:07] <mdp> summary, "grow a pair and send an email!"
  • [20:17:10] <ds2> should a box of chocolates be included?
  • [20:17:39] <mranostay> roses i'd go for roses
  • [20:17:45] <mrpackethead_> roses suck
  • [20:19:11] <ds2> is there another P/N for a am335x pin compatible device w/o ethernet?
  • [20:19:32] <mrpackethead_> jkridner_: would i be right in assuming that if you join the pins together
  • [20:20:00] <mrpackethead_> and you effetively loose the functionality of the other pin.
  • [20:20:22] <mrpackethead_> or better to say;
  • [20:20:53] <mrpackethead_> you can then choose 1 pin function out of the set of all the functions of the joined pins
  • [20:21:15] <jkridner_> yeah, the other ball/pin would need to be disabled to use the new function.
  • [20:21:27] * mhaberler (~mhaberler@macbook.stiwoll.mah.priv.at) Quit (Ping timeout: 244 seconds)
  • [20:21:35] <mrpackethead_> mmm
  • [20:22:05] <mrpackethead_> the other thing of course, is that i've then pulled 26 pins away from other thigns
  • [20:22:20] <mrpackethead_> some of which i may well want to use :-)
  • [20:24:13] * KeatonT (~textual@unaffiliated/keatont) has joined #beagle
  • [20:26:45] * lyakh (~lyakh@dslb-094-221-098-036.pools.arcor-ip.net) Quit (Quit: thanks, bye)
  • [20:30:03] <koen> prpplague: afaik they are still not in
  • [20:31:19] * thuttu77 (~thuttu77@cs181246145.pp.htv.fi) Quit (Ping timeout: 246 seconds)
  • [20:35:53] <jkridner_> mrpackethead_: yeah, that's the challenge to you... figure out what is least likely to be needed in conjunction with your PRU MII. The mailing list is a good place for some feedback on your thoughts.
  • [20:36:39] <mrpackethead_> yes, i am writing an email about Balls to Gerald right now :-)
  • [20:37:09] <panto> goodnight ppl
  • [20:37:11] * panto (~panto@195.97.110.117) Quit (Quit: Leaving)
  • [20:37:53] <jkridner_> koen: did you see Gerald's issue with having no display output?
  • [20:38:15] <mrpackethead_> http://pastebin.com/zhpGaVj0 <-- this is the required pins
  • [20:38:58] <mrpackethead_> the formatting didtn work so well
  • [20:39:24] * jpsaman (~jpsaman@videolan/developer/jpsaman) Quit (Quit: Leaving)
  • [20:39:57] <mrpackethead_> as you can see there is enough pins to get PRUETH0 working
  • [20:41:11] * KeatonT (~textual@unaffiliated/keatont) Quit (Quit: Computer has gone to sleep.)
  • [20:41:22] <koen> jkridner_: yes
  • [20:41:38] <koen> jkridner_: I dumped the card that was in my board, which does output something onthe screen
  • [20:41:47] <koen> jkridner_: so I don't know what's happening
  • [20:42:26] <jkridner_> k. :( hopefully robclark will have an idea.
  • [20:42:47] <mrpackethead_> ok.. Sent the balls
  • [20:42:49] <mrpackethead_> :-)
  • [20:42:54] <jkridner_> mrpackethead_: which column is what?
  • [20:43:05] <robclark> jkridner_, still not getting display?
  • [20:43:29] <jkridner_> intermittent per boot. Gerald didn't get any when he tried.
  • [20:43:31] <mrpackethead_> first two colums are teh Ball id's
  • [20:43:46] <mrpackethead_> for the PRUETH functions
  • [20:43:47] <robclark> hmm
  • [20:44:16] <XorA> sounds like my beagleXM will only display on my monitor approx 1/20 boots :-(
  • [20:44:16] <mrpackethead_> first colum is for eth0, 2nd for eth1
  • [20:44:19] <robclark> jkridner_, could you put your uImage (and DT) somewhere?
  • [20:44:40] <mrpackethead_> forth colum and fifth colums are where those functions appear on P8/P9 now
  • [20:45:15] <mrpackethead_> T2, V4, T5, V3 and T13 anre the missing balls
  • [20:45:53] * arcanescu (925706ef@gateway/web/freenode/ip.146.87.6.239) Quit (Ping timeout: 245 seconds)
  • [20:48:05] <jkridner_> what is the 3rd column?
  • [20:48:14] <jkridner_> signal names?
  • [20:48:23] <jkridner_> for the MII?
  • [20:49:01] <jkridner_> based on column 4, it looks like you have what you need brought to the headers for PRUETH0
  • [20:50:07] <mrpackethead_> yes, PRUETH0 is compelte
  • [20:50:29] <mrpackethead_> its PRUETH1 that is problematic
  • [20:50:40] <jkridner_> USR0/1/2/3 will be driven 99.99% of the time.
  • [20:50:52] <jkridner_> they are consumed for the LEDs, so they aren't N/C
  • [20:51:01] <mrpackethead_> yes.
  • [20:51:14] <jkridner_> The only ones that are an option to bring to the headers are ones that are currently N/C
  • [20:51:35] <mrpackethead_> the USR0/1/2/3 are though already on the headers
  • [20:51:58] <jkridner_> where?
  • [20:52:17] <jkridner_> why didn't you give the header pin name you wanted the signals connected to?
  • [20:54:07] * Guest81526 (~bleh1@217.28.12.22) Quit (Ping timeout: 276 seconds)
  • [20:54:42] <mrpackethead_> jkridner_: opps
  • [20:54:45] <mrpackethead_> you are right
  • [20:55:01] <mrpackethead_> all of those functiosn are not there
  • [20:55:26] <mrpackethead_> grrr.
  • [20:55:33] <mrpackethead_> i've misread that
  • [20:56:34] <mrpackethead_> never mind.
  • [21:00:39] * davest (~Adium@134.134.137.71) Quit (Quit: Leaving.)
  • [21:01:09] <mrpackethead_> its forward progress.
  • [21:01:15] <mrpackethead_> establing what cna't be done is useful
  • [21:03:24] <mrpackethead_> Short answer is no. I have no desire to obsolete the capes that are already developed and any of those in the works and cause headaches in SW to handle the pin mux issues that will result.
  • [21:03:24] <mrpackethead_> Gerald
  • [21:03:35] * davest (~Adium@134.134.137.71) has joined #beagle
  • [21:03:43] <mrpackethead_> well thats that
  • [21:03:51] <woglinde> poor hobbit
  • [21:04:04] <mrpackethead_> no hobit is not upset
  • [21:04:18] <mrpackethead_> hobbit knows that often finding the solution is about findign out what are not the solutiosn
  • [21:05:14] <Crofton|work> finding solution by process of elimination
  • [21:05:28] <mrpackethead_> if you dont' consider options
  • [21:05:42] <mrpackethead_> how can you be resonably sure that you've though it through.
  • [21:06:30] * thuttu77 (~thuttu77@cs181246145.pp.htv.fi) has joined #beagle
  • [21:06:41] * davest (~Adium@134.134.137.71) Quit (Client Quit)
  • [21:22:33] * mhaberler (~mhaberler@extern-185.stiwoll.mah.priv.at) has joined #beagle
  • [21:22:34] * mhaberler (~mhaberler@extern-185.stiwoll.mah.priv.at) has joined #beaglebone
  • [21:30:58] * davest (Adium@nat/intel/x-zxyvoztgxxyjdsib) has joined #beagle
  • [21:38:04] * krajo1 (~krajo1@ip4-83-240-125-22.cust.nbox.cz) Quit (Quit: Konversation terminated!)
  • [21:38:37] * KeatonT (~textual@unaffiliated/keatont) has joined #beagle
  • [21:45:52] <jsabeaudry> How can I disable musb?
  • [21:47:57] <jsabeaudry> Comment all *MUSB* in my .config?
  • [21:49:07] <jsabeaudry> Will it break my serial console?
  • [21:49:58] <mranostay> jsabeaudry: nousb in uEnv.txt is what i do
  • [21:52:53] <jsabeaudry> mranostay, thank you that is even simpler
  • [21:58:55] <mdp> mranostay, we're lobbying for derivative with PM and USB removed.
  • [21:59:19] <mdp> mranostay, AM33Eleven
  • [21:59:37] <ds2> bah
  • [21:59:40] <ds2> remove ethernet!
  • [21:59:50] <ds2> put the 37xx PM in there
  • [22:00:05] <Jacmet> wee, laptop survived bios upgrade ;)
  • [22:00:06] <mdp> then you'll want DSS
  • [22:00:16] <mdp> ds2, where does the madness stop?
  • [22:00:17] <ds2> DSS is optional
  • [22:00:29] <mrpackethead_> what is DSS?
  • [22:00:30] <ds2> mdp: I just don't see that much use for having the ethernet there
  • [22:00:46] <ds2> the 33x display stuff is just fine
  • [22:00:51] <mdp> some people like it
  • [22:01:10] <mdp> if the driver worked they'd like it better, but it looks good on the datasheet
  • [22:01:17] <Jacmet> mdp: ;)
  • [22:01:21] <ds2> ethernet burns power
  • [22:01:40] <mdp> PCIe would solve everything ;)
  • [22:01:51] <mdp> we could forget about all this capemgr stuff
  • [22:01:52] <ds2> ARRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGG
  • [22:01:55] <mdp> ;)
  • [22:01:59] * ds2 runs screaming
  • [22:02:18] * mdp tries all the buttons and pushes the correct one for ds2.
  • [22:02:24] <mrpackethead_> ethernet means you can talk to the world.
  • [22:02:43] <ds2> you can say the same about smoke signals
  • [22:02:44] <mdp> mrpackethead_: it's wired, that's so 90s
  • [22:03:11] <ds2> and I'd be more inclined to go with the 3507
  • [22:03:47] <ds2> proven davinci emac
  • [22:05:12] <Jacmet> ds2: talking about emac, just noticed that the dm816x has 2x ethernet hwaddrs programmed in efuse even though it only has a single emac - Unless there's a 2nd hidden somewhere like the other undocumented stuff
  • [22:05:52] <ds2> maybe that is a spare one for manufacturing
  • [22:06:25] <Jacmet> ds2 that part of the control module seems identical to the am335x one
  • [22:07:31] <mdp> Jacmet: I wonder why people propagated "EMAC" in 81xx wiki docs and such..since it's cpsw
  • [22:08:00] <Jacmet> mdp: ehh, isn't it only cpsw on 814x?
  • [22:08:08] <ds2> but it is more fun to introducea whole new alphabet soup
  • [22:08:16] <Jacmet> TI is good at that
  • [22:08:52] * Tartarus (trini@46.21.157.24) Quit (Excess Flood)
  • [22:09:01] * Tartarus (trini@pixelshelf.com) has joined #beagle
  • [22:09:27] <Jacmet> mdp: I've just started working on a 816x board at work, and I'm fairly sure it isn't cpsw
  • [22:10:12] * Tartarus (trini@pixelshelf.com) Quit (Excess Flood)
  • [22:10:49] * Tartarus (trini@pixelshelf.com) has joined #beagle
  • [22:13:42] <ds2> Jacmet: does u-boot say it is a davinci emac?
  • [22:14:23] <mdp> Jacmet: I read 814x here ;) that's the one I usually play with
  • [22:14:44] <mdp> but 816x does have two of the modified emacs
  • [22:14:57] <mdp> what was that about one?
  • [22:15:45] <mdp> by modified, I mean it does gmii too unlike the old omapl versions
  • [22:17:06] <Jacmet> ds2: I don't have the board here, but I believe so
  • [22:18:59] <Jacmet> mdp: sorry, I mixed up with another device
  • [22:21:08] <mdp> it hurts my brain to remember what is what on these things
  • [22:21:38] <mdp> EMAC driver is at least a little more mature
  • [22:22:05] <Jacmet> mdp: you're not the only one
  • [22:22:38] <Jacmet> mdp: mature as in the evil ancient 81xx vendor kernel? ;)
  • [22:22:52] <mdp> u-boot driver I've seen flakiness with on am180x..nothing horrible..just occasional timeouts on a lab network where that should never happen ;)
  • [22:23:06] <mru> mdp: how about the emacs driver?
  • [22:23:10] <mdp> Jacmet: I mean on the upstream stuff
  • [22:23:40] <mdp> mru, I use a emacs driver wrapper around vim
  • [22:23:50] <Jacmet> mdp: ok, there's unfortunately very little 81xx stuff upstream (besides the stuff shared with other devices)
  • [22:24:24] * damir__ (~damir@cpe-212-85-175-204.cable.telemach.net) Quit (Quit: Leaving.)
  • [22:24:27] <mdp> Jacmet: yeah, it really is unfortunate..I have to get enough working to work on PCIe support shortly..on 814x, most likely
  • [22:24:38] <Jacmet> mdp: grant likely mentioned something about some am389x stuff he had done last year, but I haven't seen anything about it yet
  • [22:24:39] <mdp> that's the only use I have for 81xx ;)
  • [22:25:13] <Jacmet> mdp: I'm stuck with a 8168 here mainly for political reasons
  • [22:25:35] <mdp> Jacmet: yeah, he's popped up a couple times about that...we chatted at plumbers the other year about it
  • [22:25:53] <mdp> Jacmet: somebody hates you there?
  • [22:26:28] <Jacmet> mdp: I mailed him back in December where he mentioned that he had to cleanup/remove something he did for a customer before he could post it, should mail him again
  • [22:26:34] <Jacmet> mdp: something like that
  • [22:27:13] <mdp> Jacmet: oh good..I'll nag him too..I need a devel platform off of mainline on either one of those parts
  • [22:28:02] <Jacmet> mdp: I think 814x seems a better bet than 816x
  • [22:28:15] <mdp> oddly, he asked about edma dmaengine and if it applied to ti81xx recently so it made me wonder how far he really was if he didn't know it applied to ti81xx too
  • [22:28:49] <mdp> Jacmet: yeah, I've done some u-boot devel on the 814x board and it was very solid for me..so that's my comfy place to go first
  • [22:28:56] <mdp> either one has the IP I need to work on
  • [22:29:01] <Jacmet> mdp: yes, remember the mail. As far as I remember, that was back in sep/oct
  • [22:29:25] <mdp> maybe that completed some of the puzzle he wasn't yet at
  • [22:29:36] <Jacmet> mdp: is there anything funky about the pcie? I heard rumours about stability issues on 816x
  • [22:30:01] <mdp> if he didn't need spi, mmc, etc. then maybe wasn't initially important
  • [22:30:22] <mdp> Jacmet: I'm still coming up to speed...been sifting through tremendous errata
  • [22:30:33] * KeatonT (~textual@unaffiliated/keatont) Quit (Quit: Textual IRC Client: http://www.textualapp.com/)
  • [22:30:49] <Jacmet> mdp: the plan is here to stream uncompressed video + network traffic from fpga over pcie, so I guess I'll learn sooner or later
  • [22:30:49] <mdp> it's all unclear to me if the s/w folks involved had any prior pci experience
  • [22:30:54] <mdp> but that's another story
  • [22:31:03] <mdp> yeah, me too
  • [22:31:13] <mdp> PCIe is important on these new parts
  • [22:31:26] <mdp> like the J6 they just announced..hence my interest
  • [22:31:26] <Jacmet> mdp: I'm definately interested if something happens on mainline side for 81xx
  • [22:32:02] <mdp> well, I think I'll help at least residually...for me, it's a way to get the PCIe support upstream pre-silicon
  • [22:32:17] <Jacmet> mdp: J6?
  • [22:32:22] <mdp> other than that, I have to admit, it would be ok if 81xx fell of the end of the earth ;)
  • [22:32:35] <mdp> jacinto 6
  • [22:32:52] <Jacmet> mdp: yeah, me too, but seems I'm stuck with it for now
  • [22:33:06] <mdp> yeah, me too..it's all I've got
  • [22:33:15] <mdp> I'll give you a heads up as I get into it
  • [22:33:27] <mdp> should help with what you are doing
  • [22:34:02] <mdp> I almost feel bad about how TI has treated 81xx wrt upstream, but then I remember it's not my fault ;)
  • [22:34:19] <Jacmet> mdp: thanks
  • [22:34:21] <Jacmet> and heh
  • [22:34:46] * davest (Adium@nat/intel/x-zxyvoztgxxyjdsib) Quit (Quit: Leaving.)
  • [22:36:38] <mdp> it's caused us epic pain on am33xx..since they share so much..imagine if ti81xx was all upstream even 2 years after announcing it. ;)
  • [22:36:49] <mdp> pay now or pay later
  • [22:38:12] <Jacmet> mdp: yes, as I'm moving from am33xx to 81xx a lot of it seems very familiar
  • [22:39:20] * Jacmet ponders if the J6 means that there's a 81xx replacement coming up ..
  • [22:40:13] <mdp> J6 is pretty much just automotive markets if you follow the PR and marketing positioning
  • [22:41:58] <Jacmet> mdp: yes. I cannot claim to really follow/understand all the different devices / markets, but the J5 seems quite similar in architecture to 81xx
  • [22:42:02] * cosmo1t (znc@cosmo.2y.net) Quit (Ping timeout: 255 seconds)
  • [22:42:26] <mdp> J6 is weird, take a look at the block diagram
  • [22:42:52] <mdp> they call it OMAP(tm) and that tells you it comes from that org
  • [22:43:08] <ds2> uh...
  • [22:43:16] <ds2> OMAP3530 ;)
  • [22:43:24] <mdp> ok, always exceptions
  • [22:43:27] <mdp> but these days...
  • [22:43:32] <ds2> :D
  • [22:43:51] <mdp> always exceptions with TI naming..that's the rule.
  • [22:43:56] <ds2> isn't that a dead man walking name? ;)
  • [22:44:08] <mdp> Jacmet: http://www.ti.com/product/dra746?DCMP=omap-jac6-130107&HQS=omap-jac6-pr-pf
  • [22:44:29] * cosmo1t (znc@cosmo.2y.net) has joined #beagle
  • [22:45:01] <mdp> notice it has both SDMA and EDMA on it ;)
  • [22:45:29] <mru> and CDMA?
  • [22:45:44] <mdp> mru, yes, going after the .us market with that
  • [22:45:47] <mdp> very important
  • [22:45:52] <mdp> and SUV support
  • [22:45:54] <Jacmet> mdp: yeah. Single ivahd?
  • [22:45:59] <ds2> no WCDMA?
  • [22:46:06] <mru> HDMA?
  • [22:46:23] <mdp> ds2, if you ask marketing, it's got whatever you need
  • [22:46:33] <mdp> including QNX
  • [22:46:53] <ds2> I have long decided that I don't ask marketing anything :D
  • [22:47:13] <mdp> ds2, it can be played as a drinking game.
  • [22:48:11] <mdp> Jacmet: but in any case, note the PCIe Gen 2 there.
  • [22:48:19] <mdp> Pizza:30, bbl
  • [22:48:27] <mranostay> life is a drinking game :)
  • [22:48:28] <Jacmet> mdp: yes, like ti81xx
  • [22:48:42] <mru> what mranostay said
  • [22:49:42] * woglinde (~henning@f052016073.adsl.alicedsl.de) Quit (Ping timeout: 252 seconds)
  • [22:52:56] * ds2 (noinf@netblock-66-245-251-24.dslextreme.com) Quit (Ping timeout: 252 seconds)
  • [22:56:33] <Jacmet> mdp: besides pcie, are there mainline plans for J6?
  • [22:56:55] * smplman_ (~speery@cn-sfo1-natout.cnet.com) has joined #beagle
  • [23:00:28] * smplman (~speery@cn-sfo1-natout.cnet.com) Quit (Ping timeout: 256 seconds)
  • [23:00:28] * smplman_ is now known as smplman
  • [23:05:51] * dv_ (~quassel@chello080108009040.14.11.vie.surfer.at) Quit (Ping timeout: 245 seconds)
  • [23:11:44] * dv_ (~quassel@chello080108009040.14.11.vie.surfer.at) has joined #beagle
  • [23:12:51] * KeatonT (~textual@unaffiliated/keatont) has joined #beagle
  • [23:16:28] * dv_ (~quassel@chello080108009040.14.11.vie.surfer.at) Quit (Ping timeout: 252 seconds)
  • [23:17:08] * hattwick (~hattwick@68-184-17-253.dhcp.unas.ma.charter.com) Quit (Ping timeout: 255 seconds)
  • [23:19:16] * hattwick (~hattwick@68-184-17-253.dhcp.unas.ma.charter.com) has joined #beagle
  • [23:20:15] * florian (~fuchs@Maemo/community/contributor/florian) Quit (Quit: Verlassend)
  • [23:20:38] * florian (~fuchs@sign-4d094c9a.pool.mediaWays.net) has joined #beagle
  • [23:20:39] * florian (~fuchs@sign-4d094c9a.pool.mediaWays.net) Quit (Changing host)
  • [23:20:39] * florian (~fuchs@Maemo/community/contributor/florian) has joined #beagle
  • [23:22:08] * nashpa (~nashpa@dliviu.plus.com) has joined #beagle
  • [23:22:09] * nashpa (~nashpa@dliviu.plus.com) has joined #beagleboard
  • [23:23:44] * dv_ (~quassel@chello080108009040.14.11.vie.surfer.at) has joined #beagle
  • [23:31:20] * Splats (~splats@unaffiliated/splats) Quit (Ping timeout: 240 seconds)
  • [23:31:36] * kkeller (~Ken_Kelle@174-17-17-245.phnx.qwest.net) Quit (Quit: Leaving.)
  • [23:31:45] <mranostay> Jacmet: "patches are welcome" is the mainine plans probably :P
  • [23:34:07] * florian (~fuchs@Maemo/community/contributor/florian) Quit (Quit: Verlassend)
  • [23:38:47] * thurbad_ (~natesewel@64.132.24.36) Quit (Quit: thurbad_)
  • [23:44:33] * sh1v (~sh1v@confluxhost.com) has joined #beagle
  • [23:49:18] * NishanthMenon (~nmenon@192.91.66.186) Quit (Quit: There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence.)
  • [23:53:37] * dj_pi (~asd@c-107-5-25-243.hsd1.mi.comcast.net) has joined #beagle
  • [23:59:24] * smplman (~speery@cn-sfo1-natout.cnet.com) Quit (Quit: smplman)