**** BEGIN LOGGING AT Thu Jan 24 02:59:59 2013
Jan 24 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.
Jan 24 04:02:05 <yates> are daughtercards interfacing via the P9 expansion connector on the beagleboard xm required to have an eeprom for pin muxing?
Jan 24 04:04:52 <jkridner_> the beagleboard-xm kernel doesn't have an EEPROM format to define pin muxing as far as I know.
Jan 24 04:05:01 <jkridner_> you have to use buddy= in your kernel command line.
Jan 24 04:05:55 <jkridner_> or set the pin muxing at run-time if there isn't already kernel support for your hardware.
Jan 24 04:06:33 <jkridner_> seems like something we can go back and support with not-capebus soon (TM)
Jan 24 04:06:46 <yates> i guess i'm totally confused about this.
Jan 24 04:06:57 <yates> what data does the eeprom provide?
Jan 24 04:07:24 <jkridner_> EEPROM isn't required on BeagleBoard-xM beagle-buddy boards, only BeagleBone capes
Jan 24 04:07:48 <yates> by "beagle-buddy" do you mean P9 interfaces?
Jan 24 04:08:00 <yates> i'm on the rev c.1.0
Jan 24 04:08:00 <jkridner_> oh, wait...
Jan 24 04:08:07 <jkridner_> I forgot, we did define an EEPROM standard.
Jan 24 04:08:08 <yates> of the bbxm
Jan 24 04:08:15 <jkridner_> my bad... man am I out of whack.
Jan 24 04:08:20 <jkridner_> http://elinux.org/BeagleBoardPinMux#EEPROM_content
Jan 24 04:08:20 <yates> np.
Jan 24 04:08:35 <yates> i very much appreciate your help, jkridner_
Jan 24 04:09:07 <jkridner_> wow, there's several more boards since the last time I looked.
Jan 24 04:09:33 <yates> i'm still pretty confused
Jan 24 04:09:40 <yates> how does the eeprom get programmed?
Jan 24 04:11:08 <yates> it looks like it connects to the i2c bus on the board
Jan 24 04:11:08 <jkridner_> you can write to it from the command-line if it wasn't previously programmed.
Jan 24 04:11:14 <jkridner_> yes, it does.
Jan 24 04:11:17 <yates> via linux?
Jan 24 04:12:10 <jkridner_> yes, or u-boot, but typically Linux.
Jan 24 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 ?
Jan 24 04:14:10 <jkridner_> or other functions.
Jan 24 04:14:38 <mrpackethead_> jkridner_: thanks, that was a question i was going to have to ask shorlty
Jan 24 04:14:42 <mrpackethead_> about the EEPROM
Jan 24 04:16:36 * jkridner_ thinks we need to do something to consolidate the EEPROM formats between BeagleBoard and BeagleBone to avoid long-term confusion.
Jan 24 04:16:37 <jkridner_> :(
Jan 24 04:16:56 <jkridner_> the two formats are totally different.
Jan 24 04:17:04 <mrpackethead_> the beagleboard is probably a dead duck though?
Jan 24 04:17:30 <yates> mrpackethead_: do you mean the bbxm?
Jan 24 04:17:41 <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.
Jan 24 04:17:51 <jkridner_> the kernel's been revved pretty well.
Jan 24 04:18:13 <yates> jkridner_: by the way, i've gotten 3.7.4 to boot on the bbxm just yesterday.
Jan 24 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.
Jan 24 04:18:33 <mrpackethead_> what i want is a beaglebone, that had access to the the PRU's MII ports.
Jan 24 04:18:49 <mrpackethead_> i really want to have a linux bases system with ethercat
Jan 24 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)?
Jan 24 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?
Jan 24 04:19:33 <jkridner_> if they are used, it'll never happen.
Jan 24 04:19:49 <mrpackethead_> jkridner_: sadly, its 4 pins short..
Jan 24 04:19:56 <mrpackethead_> which are just not connected
Jan 24 04:19:56 <jkridner_> if they can be added to other pins and muxing would avoid interference, there is a chance.
Jan 24 04:20:21 <jkridner_> if they are totally N/C, you could probably propose on the list what pins they could be joined with.
Jan 24 04:20:43 <mrpackethead_> jkridner_: are you familar with the ICE board?
Jan 24 04:20:59 <jkridner_> Rev A6 has some of these pins where there are 2 balls connected to a single expansion header pin.
Jan 24 04:21:10 <mrpackethead_> jkridner_: , i saw that
Jan 24 04:21:10 <jkridner_> I've seen it, but I don't know much about it.
Jan 24 04:21:24 <mrpackethead_> that is a clever idea
Jan 24 04:21:28 <mrpackethead_> :-)
Jan 24 04:22:21 <mrpackethead_> i just loaded Orcad last night and was looking at the design.
Jan 24 04:22:42 <mrpackethead_> i noted that quite a lot of the pins had been done like that
Jan 24 04:22:54 <mrpackethead_> i was even thinking of doing a custom build...
Jan 24 04:23:04 <mrpackethead_> converting beagle from 6 to 8 layers
Jan 24 04:23:18 <mrpackethead_> picking up the extra pins
Jan 24 04:24:23 <mrpackethead_> and pushign them out to some PHY ports
Jan 24 04:24:36 <mrpackethead_> so it wuld be very beagle, and very ICE, but all togehter.
Jan 24 04:26:00 <jkridner_> sounds like a nice board
Jan 24 04:26:09 <jkridner_> but a bit more expensive
Jan 24 04:34:57 <mrpackethead_> yes..
Jan 24 04:35:16 <mrpackethead_> jkridner_: sorry i asked you a question in PM..
Jan 24 04:35:26 <mrpackethead_> in case you did'tn want to answer it in public.
Jan 24 04:35:49 <jkridner_> I'm employed by TI and I'm one of the founders of BeagleBoard.org
Jan 24 04:35:55 <mrpackethead_> ahh.. ok.
Jan 24 04:36:09 <mrpackethead_> cool, your comments lead me to think that
Jan 24 04:36:11 <mrpackethead_> :-)
Jan 24 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.
Jan 24 04:36:33 <mrpackethead_> i'm just regretting we did'nt latch on to it earlier.
Jan 24 04:36:53 <jkridner_> Gerald designed the hardware. He's more (very) responsive on the mailing list.
Jan 24 04:37:08 <mrpackethead_> i've talked with Gerald a few times.
Jan 24 04:37:09 <jkridner_> koen did the distro
Jan 24 04:37:34 <mrpackethead_> i'm running in debian
Jan 24 04:37:38 <jkridner_> people who have worked on the kernel are many, many, many and varied.
Jan 24 04:37:43 <jkridner_> k.
Jan 24 04:37:49 <mrpackethead_> the *only* reaosn why, is its because what i was familar with
Jan 24 04:38:04 <mrpackethead_> and as yet, hav'nt come unstuck.
Jan 24 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
Jan 24 04:38:29 <mrpackethead_> yes, in deed
Jan 24 04:38:35 <mrpackethead_> his net-installer is very good as well
Jan 24 04:39:16 * jkridner_ gives up on g_multi on Mac for the moment and spends some time with the wife
Jan 24 04:39:29 <mrpackethead_> ;:-)
Jan 24 04:39:33 <mrpackethead_> you gotta do that
Jan 24 04:39:56 <alan_o> mranostay: hehe. I'm famous now :)
Jan 24 04:40:19 <mrpackethead_> alan_o: i'm a hobbit. beat that
Jan 24 04:41:22 <mrpackethead_> jkridner_: i'll take another look at the pin muxing
Jan 24 04:41:25 <mrpackethead_> and see what was missing.
Jan 24 04:41:28 <mrpackethead_> and see if its possible
Jan 24 04:41:55 <mrpackethead_> anyone else fmailar with Ethercat?
Jan 24 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?
Jan 24 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?!?
Jan 24 04:49:56 <yates> jkridner_: ps: i was contracting at TI last year (Dallas, Forest/TI Blvd), for Susan Yim in the SmartGrid group
Jan 24 04:54:18 <yates> jkridner_: hello?
Jan 24 05:02:10 <mrpackethead_> yates: hes gone to talk to his wife
Jan 24 05:02:52 <yates> oh. that's a good thing(TM)
Jan 24 05:03:10 <yates> mrpackethead_: do you knwo about this eeprom thing?
Jan 24 05:03:20 <mrpackethead_> i know that i need to know about it shortly.
Jan 24 05:03:22 <mrpackethead_> :-)
Jan 24 05:03:25 <mrpackethead_> thats not the same thign
Jan 24 05:03:38 <mrpackethead_> post to the beagle mailing list
Jan 24 05:03:40 <mrpackethead_> someone will answer
Jan 24 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?
Jan 24 05:03:45 <mrpackethead_> and generally quite quickly
Jan 24 05:04:00 <mrpackethead_> i understand that is how it works
Jan 24 05:04:08 <mrpackethead_> i've seen a format of the data as well
Jan 24 05:04:14 <mrpackethead_> your supposed to register 'capes'
Jan 24 05:04:56 <yates> capes/daughtercards/wingboards/blah blah blah
Jan 24 05:05:05 <yates> another cutesie term for the decade...
Jan 24 05:05:27 <yates> mezzanine boards
Jan 24 05:06:35 <yates> yeah, apparently the format is here: http://elinux.org/BeagleBoardPinMux#EEPROM_content
Jan 24 05:22:01 <yates> is there a linux command line utility for reading i2c devices?
Jan 24 05:22:24 <yates> LSR told me it's possible i have an unprogrammed card. Pffft!
Jan 24 05:37:36 <paddu> haii
Jan 24 05:38:44 <paddu> i want to do ne simple project UART in DM3730
Jan 24 05:39:04 <paddu> any boday can help?
Jan 24 05:40:57 <dm8tbr> do you have a linux desktop?
Jan 24 05:41:25 <mranostay> heh
Jan 24 05:41:32 <paddu> no i am using CCsv5
Jan 24 05:41:54 <paddu> i used to write code in c language
Jan 24 05:42:26 <dm8tbr> that's great, then just look up the linux serial programming howto and get kicking
Jan 24 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
Jan 24 05:45:49 <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
Jan 24 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?
Jan 24 05:49:56 <paddu> hello Ruecker r u there??????
Jan 24 05:50:17 * mranostay takes shot
Jan 24 05:50:37 <mranostay> dm8tbr: see what you did?
Jan 24 05:51:05 <paddu> what?
Jan 24 05:52:11 <paddu> from monday to this day am seeing the difference but no use
Jan 24 05:54:32 <dm8tbr> paddu: adressing me by my last name does not get you anything.
Jan 24 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...
Jan 24 05:57:28 <paddu> what is bare metal?
Jan 24 05:57:39 <dm8tbr> 'without an OS'
Jan 24 05:58:34 <paddu> no
Jan 24 06:03:50 <paddu> k bye
Jan 24 07:27:29 <mrpackethead_> yates, still here
Jan 24 07:32:27 <panto> gm trolls
Jan 24 07:33:35 <emeb_mac> who's that on the bridge?
Jan 24 07:41:43 <mrpackethead_> panto: theres hobbits here as well
Jan 24 07:42:13 <mranostay> panto: someone was asking about capemgr here even
Jan 24 07:46:13 <panto> I sorta see something
Jan 24 07:46:20 <panto> but I guess he's not around now
Jan 24 07:47:35 * mranostay pokes av500 
Jan 24 07:48:24 <mrpackethead_> i was asking about it actually
Jan 24 07:48:31 <mrpackethead_> i'm quite interested to know how it works
Jan 24 07:48:45 <mranostay> or mrpackethead_
Jan 24 07:48:47 <mranostay> er
Jan 24 07:48:56 <mranostay> rather mru
Jan 24 07:49:03 <panto> mrpackethead_, well, what do you want to know?
Jan 24 07:49:07 <mrpackethead_> mrpackethead the simple hobbit from middle-earth
Jan 24 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
Jan 24 07:50:45 * mranostay goes to sleep reading this shitty intel spec for work..
Jan 24 07:51:03 <mranostay> no offense to the intel guys here :)
Jan 24 07:52:29 <panto> mrpackethead_, there are a bunch of articles on lwn.net
Jan 24 07:52:46 <panto> there's some documents in Documentation/devicetree as well
Jan 24 07:53:15 <mranostay> panto: exact steps?
Jan 24 07:53:27 * panto kicks mranostay to bed 
Jan 24 07:57:05 <mrpackethead_> thanks panto
Jan 24 07:57:41 <mrpackethead_> there is a big learing curve with this stuff
Jan 24 07:57:58 <mrpackethead_> but 'm resoanbly pleased with how fast i've got stuff done
Jan 24 07:58:28 <av500> mranostay: yup
Jan 24 07:58:29 <panto> mrpackethead_, they tend to scare you away with big words, but it's just a tree data structure
Jan 24 07:58:46 <mrpackethead_> got my head around pin muxing today
Jan 24 07:58:58 <mrpackethead_> and got some square waves on the scope
Jan 24 07:58:58 * av500 waits to learn DT until it is a systemd module
Jan 24 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
Jan 24 07:59:22 <mrpackethead_> whats the deal with capes
Jan 24 07:59:29 <mrpackethead_> and the eeprom
Jan 24 08:00:05 <mrpackethead_> thats my other question for today
Jan 24 08:00:26 <mrpackethead_> are they a way of indentifying the cape?
Jan 24 08:02:35 <KotH> mrpackethead_: there is this document that describes DT for the ppc arch
Jan 24 08:02:50 <KotH> mrpackethead_: have a look at that, it covers most of the basics you need to know
Jan 24 08:03:00 <ka6sox> mrpackethead_, think autoconf for hardware :D
Jan 24 08:03:45 <mrpackethead_> so, Device tree is a collection of data that availabel to the OS about the hardware that is connected to it?
Jan 24 08:03:49 <panto> mrpackethead_, yes, if you setup your EEPROM data correctly, and provide a matching dtbo binary blob firmware
Jan 24 08:03:53 <mrpackethead_> and its capablality.. etc
Jan 24 08:03:59 <panto> right
Jan 24 08:04:19 <panto> there's a whole bunch of details, but you don't have to care about them
Jan 24 08:04:53 <panto> if you look into Documentation/devicetree/bindings/ you'll see documents that (should) describe each device's supported bindings
Jan 24 08:05:24 <mrpackethead_> so, is there some kind of "registration" for capes
Jan 24 08:05:48 <mrpackethead_> so, that if you buy my cape, it won't conflict with another cape?
Jan 24 08:05:51 <panto> mrpackethead_, the capeloader will read the EEPROM, and request a dtbo matchine the part-number and it's revision
Jan 24 08:06:16 <panto> mrpackethead_, it might conflict, there are a limited number of pins on the connectors
Jan 24 08:06:45 <panto> but, if there is a conflict pinmux will fail, so you run less risk of blowing up
Jan 24 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..
Jan 24 08:07:15 <panto> mrpackethead_, it's not using IDs
Jan 24 08:07:16 <mrpackethead_> there is a conflict, becuase capeloader woudl see two thigns the same
Jan 24 08:07:25 <panto> it's using PART-NUMBERs
Jan 24 08:07:28 <mrpackethead_> ok..
Jan 24 08:07:32 <mrpackethead_> Part-number or ID..
Jan 24 08:07:37 <panto> which are short ascii fragments
Jan 24 08:07:41 <mrpackethead_> so, does someone issue part-numbers
Jan 24 08:07:46 <mrpackethead_> or do we just make them up
Jan 24 08:08:02 <panto> mrpackethead_, well, you just make them up
Jan 24 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
Jan 24 08:08:40 <panto> which frankly is trivial
Jan 24 08:08:53 <mrpackethead_> yes, there shoudl be plenty of partnumers
Jan 24 08:08:56 <panto> just put something like a company prefix and you're set
Jan 24 08:09:10 <mrpackethead_> untill one day..
Jan 24 08:09:17 <panto> if you can't track part numbers for your own capes you have other problems :)
Jan 24 08:09:24 <mrpackethead_> yup
Jan 24 08:09:26 <mrpackethead_> understand
Jan 24 08:10:00 <mrpackethead_> so,  cape gets powered up for first time
Jan 24 08:10:04 <mrpackethead_> eemprom is empty
Jan 24 08:10:08 <panto> so, sanity is enforced via common sense and not via a shotgun
Jan 24 08:10:09 <mrpackethead_> you need to write it.
Jan 24 08:10:20 <mrpackethead_> appropraitely
Jan 24 08:10:30 <mrpackethead_> and then do you lock it to RO ?
Jan 24 08:10:35 <panto> mrpackethead_, you can force load a cape definition btw even when there's no EEPROM
Jan 24 08:10:50 <mrpackethead_> or do you just have to be sensible not to destroy it
Jan 24 08:11:03 <panto> typically people put a jumper to the eeprom write pin
Jan 24 08:11:23 <panto> so when they want to write the EEPROM jumper it
Jan 24 08:12:04 <mrpackethead_> ok..
Jan 24 08:12:25 <mrpackethead_> i see that there is also often some dip switches
Jan 24 08:12:34 <mrpackethead_> attacehd to the EEPROM
Jan 24 08:12:37 <panto> mrpackethead_, you can write it via sysfs
Jan 24 08:12:47 <mrpackethead_> is that so you could stack several of the same cape
Jan 24 08:12:53 <mrpackethead_> but address them differently?
Jan 24 08:14:07 <panto> hmm, so, there's write method exported via sysfs
Jan 24 08:14:09 <mrpackethead_> my cape design is quite a big 2nd project.
Jan 24 08:14:15 <panto> nm, you just use a tool
Jan 24 08:14:18 <mrpackethead_> i hope i hav'nt bitten off too much!
Jan 24 08:14:36 <panto> mrpackethead_, yes, you can stack up to 4 capes for auto-detection
Jan 24 08:14:51 <panto> the way they are differentiated is via their eeprom addresses
Jan 24 08:15:09 <mrpackethead_> ok..
Jan 24 08:15:12 <mrpackethead_> catching on
Jan 24 08:15:13 <panto> hex addresses 54-57
Jan 24 08:15:17 <mrpackethead_> i try to only ask the questions one.
Jan 24 08:15:19 <mrpackethead_> :-)
Jan 24 08:15:25 <panto> on the i2c2 bus
Jan 24 08:15:39 <mrpackethead_> along with the dreaded RTC
Jan 24 08:15:54 <panto> so again, most capes have a dip switch that allows you to switch addresses
Jan 24 08:16:16 <mrpackethead_> somthign about this community that is quite interesting is some topics seem to invoke massive amounts of discussion..
Jan 24 08:16:20 <mrpackethead_> when they seem simple.
Jan 24 08:16:39 <mrpackethead_> lol.
Jan 24 08:16:40 <panto> we all have strong opinion about the color of the bike shed
Jan 24 08:16:45 <mrpackethead_> yup.
Jan 24 08:16:51 <mrpackethead_> i have noted..
Jan 24 08:17:43 <panto> err, so I was wrong again; the sysfs interface do allows writes
Jan 24 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
Jan 24 08:18:43 <mrpackethead_> ahh
Jan 24 08:18:44 <mrpackethead_> ok.
Jan 24 08:18:47 <mrpackethead_> thats good to know
Jan 24 08:21:22 <mrpackethead_> panto: do you ahve an opinion on Real Time Clocks?
Jan 24 08:21:31 <mrpackethead_> hopefully teh trolls won't make too much noise
Jan 24 08:21:33 <ka6sox> back to round 3 of DT Wars.
Jan 24 08:21:34 <panto> they have to keep time accuratle
Jan 24 08:21:34 <mrpackethead_> they are probably asleep
Jan 24 08:21:37 <panto> *accurately
Jan 24 08:21:54 <mrpackethead_> ka6sox: you've had your turn :-)
Jan 24 08:22:28 <ka6sox> mrpackethead_, I've been around 3 turns so far and no luck.
Jan 24 08:22:35 <ka6sox> I keep missing "yet another thing"
Jan 24 08:22:51 <mrpackethead_> i'm proposing to stick a batery backed up DS1339 on teh I2C buss
Jan 24 08:23:59 <ka6sox> mru, putting 3 trees in tmpfs is excellent
Jan 24 08:24:22 <mrpackethead_> reading it sometime while the init.d scripts are running
Jan 24 08:24:29 <mrpackethead_> and setting the clock when we start up
Jan 24 08:24:40 <mrpackethead_> does that sound resoanble
Jan 24 08:25:20 <av500> hmm
Jan 24 08:25:31 <av500> a clock on i2c should be know to the kernel, no?
Jan 24 08:25:41 <av500> so why does user space need to deal with it?
Jan 24 08:25:41 <ka6sox> yes
Jan 24 08:25:45 <mrpackethead_> i dnt' know.
Jan 24 08:25:48 <mrpackethead_> doe it
Jan 24 08:25:51 <mrpackethead_> or does it not
Jan 24 08:25:57 <av500> should be handled like a RTC on a motherboard
Jan 24 08:25:58 <ka6sox> it goes thru sysfs.
Jan 24 08:26:17 <av500> on my PC, I do not read RTC in init.d
Jan 24 08:26:43 <ka6sox> doesn't it read it in rc.S?
Jan 24 08:26:44 <mrpackethead_> no, but you may well get time via ntp in userspace
Jan 24 08:26:50 <av500> sure
Jan 24 08:27:33 <mrpackethead_> so, is there much difference between getting time via NTP or from a local RTC
Jan 24 08:28:02 <av500> imagine a non-networked PC
Jan 24 08:28:11 <av500> when it boots, it gets the time from the motherboard
Jan 24 08:28:18 <av500> does that happen in init.d?
Jan 24 08:28:26 <av500> or does the kernel know about the RTC?
Jan 24 08:28:36 <mrpackethead_> i dont' know
Jan 24 08:28:39 <koen> heh
Jan 24 08:28:40 <ka6sox> it knows how to read it
Jan 24 08:28:48 <koen> 2 XXL t-shirts for FOSDEM
Jan 24 08:28:54 <koen> ehm
Jan 24 08:28:56 <koen> 5
Jan 24 08:29:01 <koen> better than nothing
Jan 24 08:29:12 <ka6sox> true
Jan 24 08:29:14 * av500 raises hans
Jan 24 08:29:15 * av500 raises hand
Jan 24 08:29:17 <av500> too
Jan 24 08:29:29 <mrpackethead_> av500: so you are tyically saying that the time is normally read by the kernel
Jan 24 08:29:39 <koen> I do have beagle shaped 1GB usb sticks
Jan 24 08:29:51 <mrpackethead_> (if its coming from an onboard RTC )
Jan 24 08:29:56 <av500> koen: 1GB for real or 1GB in partition table only?
Jan 24 08:30:33 * av500 has a quad core A7 now
Jan 24 08:31:14 <mrpackethead_> so, if i start my beagle up right now
Jan 24 08:31:26 <mrpackethead_> and its not attached to the network
Jan 24 08:31:39 <koen> av500: the label says "1GB - made in china"
Jan 24 08:31:39 <mrpackethead_> what time will it have
Jan 24 08:31:52 <av500> koen: ok, the latter :)
Jan 24 08:35:18 <av500> mrpackethead_: what I am saying is: on a PC, the kernel knows about the RTC
Jan 24 08:35:24 <av500> and can handle it
Jan 24 08:35:35 <av500> so a fixed RTC on I2C should be no different
Jan 24 08:35:48 <mrpackethead_> but its not a pac
Jan 24 08:35:49 <mrpackethead_> pc
Jan 24 08:35:50 <panto> av500, it should be exactly the same
Jan 24 08:36:04 <panto> mrpackethead_, that makes no difference to the kernel
Jan 24 08:36:10 <mrpackethead_> true
Jan 24 08:39:25 <mrpackethead_> grr.. now this bone crashes!!
Jan 24 08:40:28 <mrpackethead_> i foolishly pulled the plug on it
Jan 24 08:40:35 <mrpackethead_> and now she don't reboot
Jan 24 08:40:36 <mrpackethead_> i hate that
Jan 24 08:41:33 <mrpackethead_> that is a real problem
Jan 24 08:42:50 <mrpackethead_> panto: av500 i can understand the logic of why the kernel shoudl read the RTC
Jan 24 08:43:02 <mrpackethead_> but its not the only way is it?
Jan 24 08:43:14 <panto> it is the easiest
Jan 24 08:43:45 <panto> put your clock chip on the i2c bus, make the DT entry, and poof it should work
Jan 24 08:44:25 <mrpackethead_> i've actually got no reason not to do that
Jan 24 08:45:34 <mrpackethead_> mmm, somethigns got corrupted
Jan 24 08:45:45 <mrpackethead_> INIT: version 2.88 booting
Jan 24 08:45:46 <mrpackethead_> Using makefile-style concurrent boot in runlevel S.
Jan 24 08:45:54 <mrpackethead_> and then she just sits
Jan 24 08:46:37 <mrpackethead_> panto: i guess my real problem is I ahve no unerstanding of how the kernel works
Jan 24 08:46:45 <mrpackethead_> or how to modify or change it
Jan 24 08:46:50 <mrpackethead_> and the implicatiosn of all that
Jan 24 08:47:05 <panto> mrpackethead_, you got some reading ahead of you then :)
Jan 24 08:47:36 <mrpackethead_> yup.
Jan 24 08:48:28 <mrpackethead_> ok, so i now udnerstnad why it seems sensible to get the kernel to find the RTC
Jan 24 09:31:19 <KotH> av500: hmm? the kernel doesnt read the rtc, afaik... it's hwclock that does it
Jan 24 09:31:28 <KotH> av500: unless i'm gravely mistaken
Jan 24 09:34:33 <panto> KotH, Documentation/rtc.txt
Jan 24 09:37:12 <panto> and CONFIG_RTC_HCTOSYS
Jan 24 09:37:56 <KotH> panto: i'm currently reading the kernel sources
Jan 24 09:40:14 <panto> check drivers/rtc/hctosys.c
Jan 24 09:41:51 <KotH> panto: domo
Jan 24 09:41:55 <KotH> av500: i am gravely mistaken
Jan 24 09:42:12 <panto> historically, yes, the kernel didn't
Jan 24 09:42:28 <panto> it turns out it's easier to have him do it
Jan 24 09:44:32 <KotH> juup, files says (c) 2005
Jan 24 09:44:36 <KotH> that's not that long ago
Jan 24 09:44:42 <av500> ic
Jan 24 09:44:50 <av500> I thought it was done by kernel always
Jan 24 09:45:25 <panto> histerical reasons on the pc
Jan 24 09:46:42 <av500> ic
Jan 24 09:47:40 <Russ> mrpackethead_, I keep tellin' ya, hwclock.sh
Jan 24 09:50:42 <mrpackethead_> Russ, so your telling me somerhign differnet from Av500 and panto
Jan 24 09:51:15 <panto> mrpackethead_, no, it's the same thing
Jan 24 09:51:33 <panto> hwclock will use any hardware clock device
Jan 24 09:52:36 <mrpackethead_> sorry, i thought hwclock was in userspace?
Jan 24 09:52:44 <mrpackethead_> is it in the kernel?
Jan 24 09:53:13 <Russ> its a userspace way of setting system time by a clock
Jan 24 09:53:14 <panto> it's in userspace, but it accesses the rtc device which is in the kernel
Jan 24 09:59:09 <KotH> hw access is almost always in the kernel...
Jan 24 09:59:28 <KotH> unless people use stuff like /dev/exynos-mem or x11
Jan 24 10:09:20 <mrpackethead_> ok, i'll put it in the kernel. ( something new to learn )
Jan 24 10:09:22 <mrpackethead_> but..
Jan 24 10:09:37 <mrpackethead_> if i used a differnet clock source.. ( say a GPS )
Jan 24 10:09:46 <mrpackethead_> where woudl they live
Jan 24 10:09:48 <mrpackethead_> ?
Jan 24 10:14:49 <panto> GPSes are simple uarts I think (even when they are USB connected)
Jan 24 10:15:00 <panto> it's something for the gps daemon to do then
Jan 24 10:15:18 <av500> also a GPS might not have time when the system boots
Jan 24 10:15:25 <panto> right
Jan 24 10:15:29 <av500> only after getting a fix etc...
Jan 24 10:15:53 <mrpackethead_> yup.
Jan 24 10:16:03 <mrpackethead_> and a NTP source is similar
Jan 24 10:16:49 <mrpackethead_> GPS should be better than a Xtal controlled RTC though
Jan 24 10:17:00 <mrpackethead_> escp if you use a PPS
Jan 24 10:17:13 <panto> yeah
Jan 24 10:17:19 <KotH> mrpackethead_: most people who use external clocks like gps, dcf77, etc are feeding them trough ntp into the system
Jan 24 10:17:34 <panto> but this is something for the user space to deal with
Jan 24 10:17:39 <panto> it's not a kernel problem anymore
Jan 24 10:17:40 <mrpackethead_> something has to be stratum-1
Jan 24 10:17:42 <KotH> mrpackethead_: and gps is short term worse than an xtal
Jan 24 10:18:15 <mrpackethead_> the best GPS's can be 18 minutes before they can come online
Jan 24 10:18:21 <mrpackethead_> worst case
Jan 24 10:18:30 <mrpackethead_> if they do not have a currnet alamnac
Jan 24 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
Jan 24 10:19:22 <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
Jan 24 10:20:11 <KotH> that's why all GPSDOs use a crystal to filter the gps pps
Jan 24 10:20:11 <mrpackethead_> im sure that the jitter is not that high in good GPS
Jan 24 10:20:15 <KotH> it is
Jan 24 10:20:51 <mrpackethead_> anwyay..
Jan 24 10:21:27 <KotH> mrpackethead_: https://www.u-blox.com/images/downloads/Product_Docs/Timing_AppNote_%28GPS.G6-X-11007%29.pdf
Jan 24 10:21:44 <KotH> mrpackethead_: that's a state of the art gps timing receiver
Jan 24 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
Jan 24 10:22:43 <KotH> mrpackethead_: and that's with very good antenna position
Jan 24 10:22:54 <KotH> mrpackethead_: navigational receivers are quite a bit worse
Jan 24 10:23:00 <mrpackethead_> its way more preceiosn than i need anyway
Jan 24 10:23:31 <KotH> precision is not always what is limiting you :)
Jan 24 10:23:56 <mrpackethead_> im not using a GPS
Jan 24 10:23:59 <mrpackethead_> so not a problem
Jan 24 10:23:59 <mrpackethead_> :-)
Jan 24 10:24:04 <KotH> the effects of jitter are usually a lot worse than having an offset by the same amount
Jan 24 10:27:22 <av500> KotH: my ham coworker has some GPS 10mhz thing with TCXO
Jan 24 10:32:07 <KotH> av500: juup, a lot of ham's use GPSDOs as precision frequency standards
Jan 24 10:32:20 <KotH> av500: though i think you rather mean OCXO instead of TCXO :)
Jan 24 10:34:14 <av500> yeah
Jan 24 10:34:18 <av500> some XO
Jan 24 10:38:11 <koen> I hate platform data in i2c clients
Jan 24 10:38:26 <koen> especially when it's sugar like axis orientation and map
Jan 24 10:38:49 <koen> at least have a fallback
Jan 24 10:38:56 * koen stabs ST-E engineers
Jan 24 10:39:11 * koen gets some napalm and sets their iglooooooo on fire
Jan 24 10:41:41 <av500> I2S has an axis?
Jan 24 10:41:45 <av500> I2C
Jan 24 10:48:46 <koen> tilt-compensated compass
Jan 24 10:48:55 <koen> aka magnetometer + accelerometer
Jan 24 10:52:45 <av500> koen: but what device does it expose?
Jan 24 10:55:10 <koen> iio nodes
Jan 24 10:56:15 <koen> I suspect it's just a mems cube internally
Jan 24 11:52:06 <mdp> morning
Jan 24 11:52:21 <mdp> ugh, that was overload on techno-buzzwords for the morning
Jan 24 11:53:10 <koen> hey mdp
Jan 24 11:53:15 <mdp> hey
Jan 24 11:53:17 <panto> hi mdp
Jan 24 11:53:33 <mdp> all I hear is, "Illudium q-36 space modulator" at this point
Jan 24 11:53:46 <mdp> hi panto
Jan 24 11:56:31 <jkridner_> gm all
Jan 24 11:57:26 <koen> hey jkridner_
Jan 24 11:58:01 <panto> hi jkridner_
Jan 24 12:03:17 <mdp> gm jkridner_
Jan 24 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.
Jan 24 12:04:49 <jkridner_> I turned it on and still didn't see the network adapter.
Jan 24 12:04:55 <jackmitchell> reading the lwn newsletter, and the article about the possibly upcoming gpiod_ functions
Jan 24 12:05:23 <jackmitchell> I think it would be interesting to be able to alter the names of the gpio
Jan 24 12:05:39 <jackmitchell> for example when a driver was loaded it could take control of the gpio
Jan 24 12:06:00 <jackmitchell> rename them to something sensible for that driver and they would be then exported in sysfs
Jan 24 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
Jan 24 12:07:13 <KotH> mdp: flux capacitor?
Jan 24 12:07:24 <av500> jackmitchell: missile_launch
Jan 24 12:07:31 <jackmitchell> but all through the gpiolib interface
Jan 24 12:07:40 <jackmitchell> av500: :D
Jan 24 12:07:50 <mdp> KotH: too passive, the first option can, at least, blow up the earth
Jan 24 12:08:42 <KotH> mdp: oh.. micro black hole based warp drive turned into a weapon system?
Jan 24 12:09:10 * av500 puts on his unobtanium jacket
Jan 24 12:09:23 <mru> KotH: isn't that romulan tech?
Jan 24 12:09:44 <av500> mru: they stole it from the swiss
Jan 24 12:09:50 <panto> jackmitchell, wouldn't making only an alias in the sysfs work just the same?
Jan 24 12:09:55 <mdp> KotH: that's on my list
Jan 24 12:10:07 <panto> similar to ln -s I mean
Jan 24 12:10:14 <KotH> mru: well.. the romulans use artificial black holes as an energy source for their warp drives, instead of antimatter...
Jan 24 12:11:04 <av500> KotH: you mean they are powered by ..... bureaucracy?
Jan 24 12:11:09 <mru> wasn't there an episode where they turned one of those into a weapon?
Jan 24 12:11:17 <mru> or was it a cloaking device?
Jan 24 12:11:17 <KotH> mdp: then come over here and get your black hole at CERN :)
Jan 24 12:11:19 <mru> can't remember
Jan 24 12:11:26 <KotH> av500: lol... yes!
Jan 24 12:11:29 <mdp> panto, definitely policy to be solved in userspace by any typical method
Jan 24 12:11:44 <mdp> KotH: I have a story about that, btw.
Jan 24 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.
Jan 24 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
Jan 24 12:13:15 <mdp> s/could/couldn't
Jan 24 12:14:09 <mdp> KotH: so we got up and had a 2 hour physics lesson together...that bored him to sleep
Jan 24 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
Jan 24 12:14:16 <KotH> mdp: lol
Jan 24 12:14:41 <KotH> mdp: he really got disturbed by the news of the CERN ending the world?
Jan 24 12:14:45 <mdp> KotH: young enough to not understand people joking about a current meme
Jan 24 12:14:54 <KotH> oh..
Jan 24 12:15:05 <mdp> KotH: he was, maybe 8 during that? I can't remember how long ago it was
Jan 24 12:15:29 <KotH> mdp: hmm.. switch on of the lhc was iirc 3 or 4 years ago
Jan 24 12:15:43 <KotH> mdp: i think the lawsuit was a year or two earlier
Jan 24 12:15:44 <mdp> ok, maybe 9 then
Jan 24 12:15:49 <av500> KotH: no, it was like 8ys but time is running faster since then....
Jan 24 12:15:49 <mru> KotH: and how did they get home after that manoeuvre?
Jan 24 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?
Jan 24 12:16:12 <KotH> mru: that was never explained in the episodes :)
Jan 24 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!"
Jan 24 12:16:30 <panto> you can add a new method in gpiolib that creates an alias
Jan 24 12:16:39 <KotH> mdp: yeah...
Jan 24 12:17:08 <mdp> KotH: at that age, they don't have the BS filter enabled yet
Jan 24 12:17:13 <mdp> ;)
Jan 24 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?
Jan 24 12:17:17 <jackmitchell> ah, I was unaware that aliases could be created that easily from a kernel context
Jan 24 12:17:22 <mdp> KotH: yes!
Jan 24 12:17:29 <KotH> mdp: i know, i know.. i was the same at that age!
Jan 24 12:18:32 <mdp> jackmitchell: which driver?
Jan 24 12:18:33 <KotH> actually, it would have been more fun, if something like that would have happend in geneva
Jan 24 12:18:46 <KotH> the lhc experiments have been a real let down
Jan 24 12:19:02 <mru> didn't they find the higgs thing?
Jan 24 12:19:29 <mdp> mru, higgs' bosom?
Jan 24 12:19:34 <jackmitchell> mdp: it was a thought brought up by the gpiod_ article on lwn
Jan 24 12:19:34 <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
Jan 24 12:19:52 <KotH> mru: it's _not_ a proof that the higgs boson exists
Jan 24 12:20:09 <av500> KotH: do not spoil the excitement
Jan 24 12:20:16 <mru> well, they found something interesting at least
Jan 24 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
Jan 24 12:21:08 <mru> besides, absolute proof that _anything_ exists is impossible
Jan 24 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 :)
Jan 24 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
Jan 24 12:21:46 <mru> KotH: so it affirms the current theory
Jan 24 12:21:51 <KotH> yes
Jan 24 12:22:16 <KotH> the predictions of the standard model fit the data very will, as far as i have heard
Jan 24 12:22:25 <KotH> s/will/well/
Jan 24 12:23:00 <KotH> but then, i didnt have the time to follow all of the discussions around the lhc in the last months
Jan 24 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
Jan 24 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
Jan 24 12:26:33 <mdp> except...
Jan 24 12:26:44 <mdp> it is different ;)
Jan 24 12:27:07 <jackmitchell> mdp: yes, it's slightly different
Jan 24 12:27:29 <mdp> one is done at driver probe time and you could just modify DT and have it static for your system
Jan 24 12:27:38 <mdp> the other is a runtime policy thing
Jan 24 12:27:45 <jackmitchell> I was thinking of the am335x pin naming scheme, and how pinmuxing and such works
Jan 24 12:27:59 <mdp> quite honestly, you are talking about something that udev does for every other device in the system
Jan 24 12:28:03 <jackmitchell> would we not end up with mode0 names
Jan 24 12:28:19 <jackmitchell> or that horrific long incarnation of all the pins in one name
Jan 24 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?
Jan 24 12:30:47 <koen> udev?
Jan 24 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?
Jan 24 12:30:55 <koen> you mean debugfs?
Jan 24 12:31:03 <mdp> well, it operates in a different domain of creating dev nodes
Jan 24 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
Jan 24 12:32:20 <av500> koen: systemd!
Jan 24 12:32:23 <mdp> and yes, I realize gpioX_export_link() has been around for a long time
Jan 24 12:34:26 <mdp> jackmitchell: in any case, yes, it makes sense to want a runtime interface to create a custom link from userspace
Jan 24 12:34:50 <mdp> as panto points out, one of those exists
Jan 24 12:35:27 <panto> av500, admit it, you're in love with lenart
Jan 24 12:36:00 <mdp> blossoming young love
Jan 24 12:36:09 <panto> nothing wrong with that
Jan 24 12:37:56 <av500> he does +1 my comments :)
Jan 24 12:39:32 <panto> see, your love is not going to waste
Jan 24 12:39:39 <panto> lucky man
Jan 24 12:40:04 <mdp> jackmitchell: ln -sf /sys/class/gpio/gpio31 /home/sec_user/my_app/signals/space_modulator_enable_n
Jan 24 12:40:45 <mdp> panto, it all starts with some innocent +1's
Jan 24 12:41:09 <koen> gah, typed 'halt' out of habit instead of 'lsmod'
Jan 24 12:41:30 <mdp> koen, no gti for that one ;)
Jan 24 12:42:15 <koen> indeed
Jan 24 12:43:41 <koen> there, pressed reset button
Jan 24 12:43:47 <koen> 2 stories up
Jan 24 12:44:06 <koen> the patch from jsabeaudry to fix uboot is not working with the new musb code
Jan 24 12:44:23 <koen> kernel oopses in musb shutdown before it reaches the restart syscall
Jan 24 12:44:43 <mdp> awesome, shrunk edma series a lot by dropping mmc support
Jan 24 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
Jan 24 12:47:54 <mdp> koen, lol!
Jan 24 12:47:58 <koen> then I will not respond to requests for clarification
Jan 24 12:48:20 <koen> I have to keep my evil vendor tree relevant, you know
Jan 24 12:48:31 <mdp> koen, the funny thing is that I don't even value mmc support ;)
Jan 24 12:48:37 <mdp> all I need is serial and ethernet ;)
Jan 24 12:48:45 <mdp> so no big loss to me
Jan 24 12:51:44 <mdp> koen, working mainline would be a threat to CCO's production kernel
Jan 24 12:51:58 <koen> that's what I said
Jan 24 12:52:21 <mdp> I learned from jkridner, though, I massaged it to PC-biz-speak
Jan 24 12:53:12 <mdp> koen, if the series gets close to going in you'll just have to release the Kraken
Jan 24 12:55:19 <koen> I'll start with the hounds
Jan 24 12:55:43 <mdp> never bring a hound to a Kraken-fight
Jan 24 13:04:31 <bradfa> mdp, well, some of us would like mmc support :P
Jan 24 13:04:42 <mdp> bradfa, bah
Jan 24 13:04:54 <mdp> too controversial, you can wait
Jan 24 13:04:57 <bradfa> mdp, multi mmc would be handy....
Jan 24 13:05:23 <bradfa> mmc == controversial, lol
Jan 24 13:05:30 <mdp> I would like a quiet vacation home on the moon
Jan 24 13:05:44 <bradfa> mdp, I hear it's quiet up there
Jan 24 13:05:49 <mdp> indeed
Jan 24 13:05:52 <mru> the lack of atmosphere should ensure that
Jan 24 13:05:52 <mdp> science!
Jan 24 13:05:57 <mdp> +1
Jan 24 13:06:16 <bradfa> science refutes your +1 with a vaguely worded paper in scientific american which you have to pay for
Jan 24 13:06:29 <mdp> hehe
Jan 24 13:06:29 <bradfa> paywalls, ftw!
Jan 24 13:06:50 * bradfa wishes he could spend more time doing fun projects and less time scrambling to get product ready :(
Jan 24 13:07:21 <bradfa> maybe if I stopped responding to the beagle phorum...
Jan 24 13:07:40 <bradfa> which reminds me, I have to click on some links
Jan 24 13:07:56 <mdp> bradfa, the SNR of 5 forced me to quit reading it
Jan 24 13:08:05 <bradfa> too much signal?
Jan 24 13:08:19 <jkridner_> koen: so, is DMA enabled?
Jan 24 13:08:22 <bradfa> gah, google signin
Jan 24 13:08:28 <koen> jkridner_: for what?
Jan 24 13:08:37 <mdp> bradfa, yeah, they are crazy smart on there.
Jan 24 13:11:13 <jkridner_> USB
Jan 24 13:12:30 <koen> jkridner_: AFAICT no patches were ever posted publically
Jan 24 13:12:57 <jkridner_> k
Jan 24 13:12:59 <koen> jkridner_: and pointing to patches against 3.2.0.....
Jan 24 13:14:21 <koen> jkridner_: FWIW 'disable DMA' is the only selectable option in that menu
Jan 24 13:14:29 <jkridner_> k
Jan 24 13:14:30 <koen> so it's not really an option at all
Jan 24 13:14:49 <jkridner_> Just making sure no patches were posted that you brought in. thanks.
Jan 24 13:15:09 <koen> I have kishons patches + panto fixup
Jan 24 13:16:53 <koen> kishon wasn't aware that am335x existed since he was only looking at platforms with boardfiles :)
Jan 24 13:17:21 <mdp> lol
Jan 24 13:17:27 <av500> lol
Jan 24 13:17:34 <mdp> koen, ok, so that's a bit of a stretch of the situation..but... ;)
Jan 24 13:17:54 <koen> that's how I interpreted it :)
Jan 24 13:18:13 <av500> what puzzles me is, why all the effort to get TI SoC to mainline when TI is stopping it all?
Jan 24 13:18:23 <bradfa> av500, the rumorz!
Jan 24 13:18:27 <mdp> av500, exactly! I can't figure it out either
Jan 24 13:18:30 <koen> he does know about it now, but his communication with afzal is high latency
Jan 24 13:18:32 <av500> inertia
Jan 24 13:18:50 <koen> and full with WTFs like people not knowing how to apply 6 patches and asking for a tree
Jan 24 13:19:11 <koen> sweet, replacement probes arrived for my scope
Jan 24 13:19:20 * koen heads to the lab
Jan 24 13:20:14 <av500> what did you do to them?
Jan 24 13:20:17 <mdp> av500, a clown car, hurtling down the road at X speed loses force Y....
Jan 24 13:20:22 <panto> back
Jan 24 13:20:27 <av500> front
Jan 24 13:21:17 <mru> top
Jan 24 13:21:30 <mdp> koen, perhaps they are on opposite ends of the globe and the IP pigeons are running slow.
Jan 24 13:21:51 <mdp> bottom
Jan 24 13:22:05 <panto> up,down,up,down,left,left,right,a,a,b,b
Jan 24 13:23:14 <av500> IDDQD
Jan 24 13:23:41 <panto> bonus 1up
Jan 24 13:23:50 <mru> LIM
Jan 24 13:24:54 <jacekowski> IDKFA
Jan 24 13:26:46 <bradfa> panto, up up down down left right left right b a b a select start (2 player ftw!)
Jan 24 13:28:32 <mdp> ok, thanks, personal assistant just claimed there there's no work going on at work.
Jan 24 13:28:52 <bradfa> mdp, can netflix help here?
Jan 24 13:29:11 <av500> or a local folder
Jan 24 13:29:15 <mdp> "lots of laughing and gaming references, is it coffee break?" ;)
Jan 24 13:29:32 <mdp> bradfa, netflix..like opium
Jan 24 13:30:19 <av500> never understimate the bandwith of a local folder full of ..... movies
Jan 24 13:31:33 <bradfa> mdp, personal assistant is on irc?
Jan 24 13:31:48 <mdp> shoulder looking
Jan 24 13:31:55 * av500 blushes
Jan 24 13:31:57 <mdp> bradfa, oh plz no
Jan 24 13:32:14 * av500 waves
Jan 24 13:32:24 <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...
Jan 24 13:32:32 <mdp> ok, she says, "hi" and leaving us to our "work"
Jan 24 13:32:42 <av500> hard work
Jan 24 13:32:45 <mdp> indeed
Jan 24 13:32:49 <av500> we toil away here endlessly
Jan 24 13:32:52 <bradfa> we do!
Jan 24 13:32:57 <mdp> perilous toiling!
Jan 24 13:33:00 * av500 just fixed an ariane-5 bug
Jan 24 13:33:06 <av500> leftover code from 2ys ago
Jan 24 13:37:47 <panto> av500, those are nice
Jan 24 13:38:00 <mdp> do you warm up leftover code before using it?
Jan 24 13:38:13 <av500> its being kept warm all the time
Jan 24 13:38:22 <av500> like italian pasta sauce pot
Jan 24 13:38:27 <mdp> hold and cold running codez
Jan 24 13:38:58 <av500> you just add more tomatoes over time
Jan 24 13:39:04 <av500> and other stuff
Jan 24 13:40:38 <mdp> mmm...you made me think of the .mx equivalent..the giant mole pot
Jan 24 13:41:20 <mdp> ahh, yes, toiling
Jan 24 13:50:16 <koen> Jacmet: am3358 at 1GHz with HDMI transmitter active: less than 500mA
Jan 24 13:50:37 <koen> Jacmet: my PSU only has 0.1A granularity and it says 0.4A @ 5V
Jan 24 13:50:56 <mru> koen: what is the PRU clock?
Jan 24 13:51:02 <koen> doing 'cpufreq-set -g ondemand' drops it to 0.3A
Jan 24 13:51:11 <koen> mru: I have no idea
Jan 24 13:51:34 <mdp> mru, 200MHz
Jan 24 13:52:26 <mru> same as arm@720?
Jan 24 13:53:42 <mru> koen: btw, still in memphis
Jan 24 13:54:22 <koen> mru: ok, my parcel arrived this morning, but panto's is scheduled for next week
Jan 24 13:54:36 <koen> so I guess yours is scheduled for the 29th as well?
Jan 24 13:54:43 <mru> mine says 28th
Jan 24 13:54:50 <panto> mine is 29th
Jan 24 13:55:22 * mru hopes it's declared as something customs-friendly
Jan 24 13:59:04 <panto> mru, guns from texas?
Jan 24 14:04:25 <jkridner_> koen: does that mean we'll get rid of the USB clock limiter?
Jan 24 14:04:26 <av500> mine is in Memphis too
Jan 24 14:04:39 <av500> and 28th
Jan 24 14:15:22 <koen> jkridner_: which one do you mean, the 275MHz or the 720MHz one?
Jan 24 14:15:32 <jkridner_> the 500MHz one on start-up.
Jan 24 14:15:36 <jkridner_> I guess it is gone already?
Jan 24 14:15:39 <koen> yes
Jan 24 14:15:50 <koen> that's why the bone-whites fail on usb power
Jan 24 14:16:09 <koen> hrm, the servos take ~4A
Jan 24 14:16:16 <koen> and I haven't connected all of them yet
Jan 24 14:16:28 <koen> this 3A wallwart is not going to cut it for bone + servos
Jan 24 14:17:21 <bradfa> KotH, I got cadstar zuken pricing, one sec on phone with sales guy
Jan 24 14:18:39 <bradfa> KotH, http://algozen.com/CADSTAR_BUNDLES.htm <- packages
Jan 24 14:21:29 <av500> http://www.cnx-software.com/2013/01/24/always-innovating-mecam-is-a-49-voice-controlled-nanocopter-camera/
Jan 24 14:23:15 <jackmitchell> Always Innovating were the ones that were doing the tablet/keyboard thing years ahead of it's time
Jan 24 14:23:21 <jackmitchell> nice to see they're still playing with
Jan 24 14:23:30 <jackmitchell> things, but I wonder where they get the money from?
Jan 24 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)
Jan 24 14:24:29 <bradfa> KotH, those prices for 1 seat, multi seat gets quotes
Jan 24 14:24:34 <av500> haha: https://github.com/search?p=&q=%22id_rsa%22&ref=searchresults&type=Code
Jan 24 14:25:45 <bradfa> KotH, license is node locked to MAC address
Jan 24 14:25:59 <bradfa> they do offer 30 day full trial though
Jan 24 14:26:14 <bradfa> pricing seems halfway between altium and PADS/orcad
Jan 24 14:26:25 <mru> and nothing is easier than faking the system time
Jan 24 14:26:26 <bradfa> the lite is eagle kind of money, though
Jan 24 14:26:38 <bradfa> mru, nor mac addresses
Jan 24 14:27:25 <mru> I have a nice little .so that intercepts most libc calls returning timestamps
Jan 24 14:27:34 <mru> and applies an offset to them
Jan 24 14:27:49 <bradfa> +1
Jan 24 14:28:52 <mru> some apps stat random files looking for times after the expiry date
Jan 24 14:29:01 <mru> and also trip on "future" times
Jan 24 14:29:44 <av500> maybe an RTC over I2C over USB can help here
Jan 24 14:30:09 <av500> and a kernel command line option apply_rtc_offset :)
Jan 24 14:30:40 <mru> if you're willing to change the time globally, no tricks are needed
Jan 24 14:30:44 <mru> just change the system time
Jan 24 14:30:47 <mru> and disable ntp
Jan 24 14:30:49 <yegorich> Hi! Are there any plans to include am335x-pm-firmware.bin into linux-firmware repo?
Jan 24 14:31:02 <mru> faking it for a single process is a little harder
Jan 24 14:32:03 <mru> sometimes patching the app to bypass the check is the simplest way
Jan 24 14:32:32 <jackmitchell> koen, mdp, panto: I'm getting kernel panics due to the network stack on koens latest tree
Jan 24 14:32:52 <jackmitchell> is this something anyone is aware of or should I speak to someone with some tracebacks?
Jan 24 14:32:52 <mru> or simply patching the expiry date
Jan 24 14:32:58 <mru> as in the case of that ibm compiler
Jan 24 14:33:14 <koen> jackmitchell: you might need to disable NAPI
Jan 24 14:33:47 <jackmitchell> NAPI?
Jan 24 14:34:14 <koen> some fancy networking thing
Jan 24 14:34:19 <koen> jackmitchell: have a look at https://github.com/pantoniou/linux-bbxm/commit/1552831f45afb45e6931764a225d9cb7e1ca3816
Jan 24 14:34:36 <panto> jackmitchell, the cpsw driver is kinda b0rked
Jan 24 14:35:02 <mdp> I meant to ask, but does the author/maintainer know yet?
Jan 24 14:35:11 <panto> mdp, no idea
Jan 24 14:35:38 <mdp> ok, so this hasn't been reported on the normal lists or directly?
Jan 24 14:36:08 <panto> mdp, no
Jan 24 14:36:47 <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
Jan 24 14:37:11 <panto> and that the only way the original version worked was that the silicon was buggy
Jan 24 14:37:40 <mdp> panto, um, ok
Jan 24 14:37:49 <mdp> I'm not sure how to respond to that
Jan 24 14:37:56 <mdp> "nice"?
Jan 24 14:38:03 <panto> heh
Jan 24 14:38:12 <koen> why do I get the feeling I'm supposed to explain to PSP what they did in their own kernel?
Jan 24 14:38:27 <mdp> seriously, kinda confused as to how this is confused with some notion of being nice
Jan 24 14:38:28 <panto> I can send the patch to the lkml/linux-omap lists
Jan 24 14:38:38 <mdp> either it's right or wrong in this type of thing
Jan 24 14:38:50 <mdp> there's no semantics involved...phase of the moon..etc.
Jan 24 14:39:14 <mdp> thx, cc the author or whoever submitted
Jan 24 14:39:29 <mdp> I have nfc who owns it
Jan 24 14:39:51 <panto> me neither
Jan 24 14:40:09 <mdp> sure, since you worked on it, you have the git log in front of you
Jan 24 14:40:34 <panto> "Mugunthan V N <mugunthanvnm@ti.com>"
Jan 24 14:40:46 <mdp> it works sorta like google from my POV
Jan 24 14:41:06 <mdp> well, that clears it up
Jan 24 14:41:12 <mdp> ;)
Jan 24 14:41:24 <panto> and earlier commits by "Richard Cochran <richardcochran@gmail.com>"
Jan 24 14:41:55 <mdp> yeah, there was a thread where he extracted some broken commits from a WIP tree and submitted them upstream
Jan 24 14:42:10 <mdp> I recall seeing that on lomap
Jan 24 14:43:32 <av500> lol: http://zigg.be/noisy
Jan 24 14:45:01 <panto> mdp, btw, looks like there's smart switch driver support in mainline now
Jan 24 14:45:15 <panto> take a look in drivers/net/dsa
Jan 24 14:46:04 <panto> perhaps someone should look into getting cspw supported
Jan 24 14:46:57 <av500> what was cspw again?
Jan 24 14:47:16 <mdp> panto, perhaps
Jan 24 14:52:05 <jackmitchell> koen: disabling NAPI seemed to do the trick, thanks
Jan 24 14:52:42 <panto> jackmitchell, I noticed that too
Jan 24 14:53:09 <jackmitchell> panto: yes, it was stolen from your WIP commit
Jan 24 14:53:10 <panto> I guess the locking is all messed up for the NAPI case
Jan 24 14:53:30 <jackmitchell> I assume so, it was locking that was causing me problems too
Jan 24 14:53:39 <jackmitchell> nmap triggered it almost immediatly
Jan 24 14:53:55 <koen> jackmitchell: ok, I'll add a patch for that
Jan 24 14:54:15 <panto> IMO since the h/w support coalescing NAPI is a bit redundant
Jan 24 14:54:24 <panto> but ofcourse it doesn't support it in PG1.0 silicon
Jan 24 15:31:14 <jsabeaudry> koen, huh? is that really a problem with my patch?
Jan 24 15:39:40 <koen> jsabeaudry: no, it's problem with musb
Jan 24 15:39:45 <Jacmet> panto: the dsa stuff is pretty limited
Jan 24 15:39:53 <koen> jsabeaudry: it doesn't even reach the point that your patch fixes
Jan 24 15:40:21 <Jacmet> panto: E.G. there's no link to the vlan/bridge infrastructure in the kernel
Jan 24 15:40:32 <panto> Jacmet, it's still a place to start
Jan 24 15:40:36 <Jacmet> panto: sure
Jan 24 15:40:48 <panto> that doing it totally proprietary
Jan 24 15:40:50 <panto> *than
Jan 24 15:41:12 <Jacmet> panto: dsa pretty much halted when Lennert left Marvell
Jan 24 15:41:28 <panto> figures
Jan 24 15:43:50 <yates> where is the format of the EEPROM data defining the pinmuxing defined?
Jan 24 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
Jan 24 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.
Jan 24 15:49:31 <panto> yates, pay not much attention to the pinmuxing in the eeprom of the capes
Jan 24 15:49:51 <panto> afaikt it's mostly for bootloader use
Jan 24 15:50:11 <panto> linux doesn't use it at all
Jan 24 16:05:59 <mdp> panto, I updated the edma binding and codez for #dma-cells = <2> so the client device can specific a queue
Jan 24 16:06:19 <mdp> panto, useful for my updated asoc patches in the short-term
Jan 24 16:06:32 <panto> I see
Jan 24 16:06:59 <mdp> long-term..dmaengine has to also support that on a channel request
Jan 24 16:08:17 <mdp> that was the intention of cells>1 anyway in the generic binding
Jan 24 16:08:24 <mdp> s/binding/dma binding/
Jan 24 16:25:20 <jsabeaudry> Recommendations for the best 3.2 tree for beaglebone?
Jan 24 16:26:21 <av500> device tree
Jan 24 16:26:54 <jsabeaudry> kernel
Jan 24 16:27:03 <ottoman> helloworld.
Jan 24 16:27:17 <av500> .?
Jan 24 16:27:28 <jsabeaudry> linux-omap, koen's last 3.2, beagleboard/kernel, other?
Jan 24 16:27:30 <mru> av500: is that a regexp?
Jan 24 16:27:47 <koen> jsabeaudry: beagleboard/kernel and 'my' 3.2 are the same
Jan 24 16:27:58 <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
Jan 24 16:28:02 <koen> jsabeaudry: one is just a git tree resulting from running the patch.sh script
Jan 24 16:28:08 <ottoman> anyone have the ARM RVI debugger working?
Jan 24 16:28:27 <mru> I'm sure _someone_ does
Jan 24 16:28:42 <mru> I'm also fairly sure it's not you
Jan 24 16:29:16 <ottoman> alright.
Jan 24 17:09:09 <KotH> bradfa: thanks!
Jan 24 17:09:47 <bradfa> KotH, welcome
Jan 24 17:09:50 <KotH> bradfa: the prices seem ok..still quite expensive, but ok
Jan 24 17:09:53 <bradfa> not quite "low prices"
Jan 24 17:10:39 <KotH> bradfa: you didnt ask about the cr-5000/8000?
Jan 24 17:10:47 <bradfa> no, sorry
Jan 24 17:11:27 <bradfa> didn't notice them...
Jan 24 17:11:31 * bradfa needs to read better
Jan 24 17:11:32 <KotH> :-)
Jan 24 17:11:53 <KotH> bradfa: the video with the 3d stuff from yesterday was the cr-8000
Jan 24 17:11:57 <bradfa> ah, ok
Jan 24 17:12:49 <KotH> i wouldnt be surprised if that stuff is twice the price
Jan 24 17:12:56 <bradfa> from the looks, you're probably right
Jan 24 17:14:26 <bradfa> hmmm, not good -> kernel:[183985.264174] journal commit I/O error
Jan 24 17:14:41 * KotH hands bradfa a new hd
Jan 24 17:14:49 * bradfa scrambles to do backup!
Jan 24 17:15:29 * KotH wonders if zuken would give out cheap version of their software for hobbists
Jan 24 17:15:44 <bradfa> KotH, free 30 day trial
Jan 24 17:16:09 <KotH> bradfa: yeah... and then crack it to extend that 30day...
Jan 24 17:16:22 <bradfa> KotH, play mru's "change the date" game :)
Jan 24 17:16:42 * bradfa 's backup now in progress
Jan 24 17:16:48 * bradfa crosses fingers that ssd isn't dead...
Jan 24 17:17:03 <bradfa> or dying
Jan 24 17:17:19 <bradfa> maybe a good excuse to pawn the laptop onto someone else and buy a real computer
Jan 24 17:17:31 <XorA> :-D
Jan 24 17:17:53 <bradfa> I have my eye on an Intel Xeon system
Jan 24 17:18:17 <KotH> for a laptop?
Jan 24 17:18:18 <KotH> ;)
Jan 24 17:18:26 <bradfa> KotH, if only!
Jan 24 17:18:33 <bradfa> I'd like something with real serial ports
Jan 24 17:18:35 <bradfa> I'm sick of USB
Jan 24 17:18:41 <KotH> hehe
Jan 24 17:18:46 <KotH> these are hard to get these days
Jan 24 17:18:49 <bradfa> USB is OK for keybaords and mice, everything else should use a real bus
Jan 24 17:18:57 <bradfa> like serial
Jan 24 17:19:01 * XorA has real hard seriel ports, every second kernel release 8250 driver is broken :-(
Jan 24 17:19:01 <ynezz> sure
Jan 24 17:19:02 <bradfa> or PCI, I guess
Jan 24 17:19:05 <KotH> bradfa: and just to make you envious: my home desktop is an dual xeon system :)
Jan 24 17:19:18 * bradfa sneaks over to KotH's house and steals computer
Jan 24 17:19:27 <KotH> bradfa: you probably dont want to
Jan 24 17:19:30 * bradfa 's home desktop is a 7 year old dual Opteron
Jan 24 17:19:36 <KotH> it's a 7y old HP ML110
Jan 24 17:19:43 <bradfa> so we're in the same age group!
Jan 24 17:19:47 <KotH> juup
Jan 24 17:19:48 <crashovrd> oh how cute, u have x86 systems
Jan 24 17:19:53 <KotH> lol
Jan 24 17:20:05 <bradfa> I've got a 400GBx4 RAID5 on PCI-X
Jan 24 17:20:10 <bradfa> it was fast, 7 years ago
Jan 24 17:20:13 <KotH> bradfa: the oly good thing about this box is, that it has 8gb of ram
Jan 24 17:20:22 <bradfa> KotH, I've got 2 at home, 8 in the lappy
Jan 24 17:20:25 <KotH> bradfa: otherwise i would have thrown it out already
Jan 24 17:20:29 <bradfa> Next desktop won't have less than 32
Jan 24 17:20:39 <bradfa> builds go in tmpfs, where they belong
Jan 24 17:21:01 <ynezz> in that time you would need like 64GB
Jan 24 17:21:03 <KotH> bradfa: same here, my laptop has a i7 with 8gb mem
Jan 24 17:21:12 <ynezz> systemd is growing...
Jan 24 17:21:19 <bradfa> ynezz, systemd, you're funny :)
Jan 24 17:22:08 <bradfa> Dell has some decent Xeon systems for reasonable prices these days
Jan 24 17:22:21 <bradfa> I'm uncertain if building my own box is worth it any more
Jan 24 17:22:26 <bradfa> other than buying my own ram and ssds
Jan 24 17:22:45 <ynezz> Dell is going bankrupt...
Jan 24 17:23:03 <bradfa> ynezz, well, HP or Lenovo, then
Jan 24 17:23:08 <crashovrd> and intel is exiting the motherboard biz
Jan 24 17:23:17 <mdp> I heard amazon is buying all of them
Jan 24 17:23:18 <bradfa> crashovrd, desktop motherobard biz
Jan 24 17:23:19 <KotH> crashovrd: huh? what?
Jan 24 17:23:21 <bradfa> not server / workstation
Jan 24 17:23:32 <crashovrd> *desktop* motherboard biz
Jan 24 17:23:37 <bradfa> KotH, in like 3 years intel says they're getting out of the desktop motherboard manufacturing biz
Jan 24 17:23:48 <KotH> sounds strange
Jan 24 17:23:51 <bradfa> they'll still make chipsets
Jan 24 17:23:53 <KotH> took them agaes to get in...
Jan 24 17:24:04 <bradfa> KotH, they have planety of time to change their minds
Jan 24 17:24:05 <bradfa> :)
Jan 24 17:24:11 <KotH> *g*
Jan 24 17:24:48 <ynezz> well, there would be no desktop at that time
Jan 24 17:25:08 <mdp> ahh, yes,,the ever-useful "3 year business plan"
Jan 24 17:25:09 <ynezz> you'll just put your car keys in docking station...
Jan 24 17:25:12 <mdp> duh
Jan 24 17:25:30 <bradfa> mdp, you'll be glad to know the plows came back and plowed one strip down the parking lot
Jan 24 17:25:35 <bradfa> rest is still snow covered
Jan 24 17:25:48 <bradfa> ynezz, more like put Credit Card in slot
Jan 24 17:26:00 <mdp> bradfa, they are at the donut shop, most likely
Jan 24 17:26:27 <ynezz> bradfa: CC with 64GB of RAM?
Jan 24 17:26:35 <bradfa> smart cards!
Jan 24 17:26:41 <KotH> that's comming!
Jan 24 17:26:49 <bradfa> with "encryption"!
Jan 24 17:26:55 <KotH> hehe
Jan 24 17:27:20 <bradfa> encryption solves everything!
Jan 24 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
Jan 24 17:28:27 <mdp> the level of effort to put the mobo/cpu in a case is hardly worth purchasing the wrong thing
Jan 24 17:28:34 <bradfa> yeah
Jan 24 17:28:38 <bradfa> true
Jan 24 17:29:01 <mdp> I mean, they're going to have the wrong ram and ssd to start as you point out anyway
Jan 24 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
Jan 24 17:29:21 <crashovrd> its an intel something... something.. something
Jan 24 17:29:36 <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
Jan 24 17:29:37 <mdp> crashovrd: I'll forget soon
Jan 24 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
Jan 24 17:30:50 <crashovrd> there is just no payoff anymore to building the ULTIMATE pc
Jan 24 17:30:56 <crashovrd> there is only so fast you can run a web browser
Jan 24 17:31:14 <mdp> sure, always exception features..depends on what you value
Jan 24 17:31:19 <crashovrd> how fast do you need a wordprocessor to go?
Jan 24 17:31:50 <KotH> crashovrd: blazingly fast!
Jan 24 17:31:54 <bradfa> crashovrd, even faster!
Jan 24 17:32:06 <crashovrd> i did find it amusing that Visual Studio 2010 and higher have *hardware* acceleration
Jan 24 17:32:11 <crashovrd> for the GUI
Jan 24 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
Jan 24 17:32:51 <mdp> bradfa, and I have a particular taste for a few old pci slots and a real 8250 too
Jan 24 17:33:07 <KotH> mdp: not a 16550?
Jan 24 17:33:12 <bradfa> oh, don't get me wrong, what ever desktop I buy will have gobs of serial ports
Jan 24 17:33:13 <mdp> :)
Jan 24 17:33:19 <crashovrd> he's got a PC XT
Jan 24 17:33:21 <crashovrd> :P
Jan 24 17:33:22 <bradfa> I hate this usb crap
Jan 24 17:33:23 <mdp> KotH: I don't believe in FIFOs!
Jan 24 17:33:35 * KotH remembers the time, when mainboards put the type of their uart as a major feature
Jan 24 17:33:56 <bradfa> KotH, to some of us, we still consider that a very important feature
Jan 24 17:33:56 <bradfa> :)
Jan 24 17:34:00 <mdp> bradfa, oh come now...don't take your frustration out on USB...it's completely innocent.
Jan 24 17:34:27 <bradfa> gimme PS/2, mechanical keyboard, some serial ports, and OK maybe some firewire
Jan 24 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)
Jan 24 17:35:15 <crashovrd> who would have thought that all these years later we would be back to serial buses
Jan 24 17:35:33 <mdp> crashovrd: yet we loved it...it was much better than loading from cassette.
Jan 24 17:35:58 <mdp> then have your sister take the same cassette and record singing over it..wtf?
Jan 24 17:36:03 <mdp> boo
Jan 24 17:36:25 <KotH> bradfa: exsys still sells rs-232 cards for pci-e
Jan 24 17:36:42 <KotH> bradfa: like the ex-44098, an 8port card :)
Jan 24 17:36:48 <bradfa> KotH, links?
Jan 24 17:36:51 <crashovrd> oh! lets start a BBS
Jan 24 17:36:54 <mdp> KotH: how can there be a market with all the awesome usb ones? ;)
Jan 24 17:37:00 <KotH> bradfa: http://www.exsys-shop.ch/shop/product_info.php?info=p528_PCIe-8S-Seriell-RS-232-Karte--Oxford.html
Jan 24 17:37:11 <KotH> bradfa: dunno whether there is an english site
Jan 24 17:37:15 <mdp> crashovrd: see you on FidoNET
Jan 24 17:37:24 <crashovrd> +++ATH
Jan 24 17:37:29 <KotH> mdp: uhmm.. there seem to be enough crazy people like you around
Jan 24 17:37:37 <bradfa> KotH, yes! nice find!
Jan 24 17:37:45 <KotH> crashovrd: you forgot the pause between the +++ and the ATH :)
Jan 24 17:37:47 <bradfa> don't even get me started on USB to serial converters
Jan 24 17:37:53 <bradfa> there's 1 good kind, the rest suck
Jan 24 17:37:56 <mdp> KotH: s/crazy people/people that need shit that works/
Jan 24 17:38:08 <KotH> bradfa: exsys is your friend when it comes to strange adapter cards and systems
Jan 24 17:38:10 <bradfa> hint: the good kind isn't made by ftdi
Jan 24 17:38:21 <KotH> bradfa: i buy often their stuff. it's not the cheapest but it works very well
Jan 24 17:38:35 <bradfa> KotH, but it eats USB bus
Jan 24 17:38:51 <bradfa> if you have a few interrupt end points on the same bus with an FTDI, everybody gets pissed off
Jan 24 17:39:00 <KotH> bradfa: what do you mean "eats usb"?
Jan 24 17:39:11 <KotH> ah..
Jan 24 17:39:14 <KotH> dont use ftdi
Jan 24 17:39:24 <bradfa> KotH, they use quite a lot of USB bus bandwidth the way they get setup, at least on widnwos boxes
Jan 24 17:39:34 <bradfa> makes running a Saele logic difficult
Jan 24 17:39:37 <bradfa> it also eats bus
Jan 24 17:39:49 <mdp> bradfa, btw, local company a friend used to work for: http://www.quatech.com/products/serialboards.php
Jan 24 17:39:51 <KotH> bradfa: yeah
Jan 24 17:40:09 <mdp> bradfa, same stuff, I've used it before..they also have some other cool quirky IO things ;)
Jan 24 17:40:11 <KotH> bradfa: friend tried an ftdi i2c usb dongle
Jan 24 17:40:26 <KotH> bradfa: got horrified after he noticed that every bit requires an usb transaction
Jan 24 17:40:31 <bradfa> http://www.exsys-shop.ch/shop/product_info.php?info=p297_PCIe-8S-Seriell-RS-232-Module.html
Jan 24 17:40:55 <bradfa> I want that!
Jan 24 17:41:21 <KotH> *g*
Jan 24 17:42:36 <mdp> bradfa, don't you need a parallel port too?
Jan 24 17:42:41 <bradfa> mdp, yes
Jan 24 17:42:46 <bradfa> so I can bit twiddle
Jan 24 17:43:13 <mdp> quatech has the expresscard versions too ;)
Jan 24 17:43:34 <mdp> or rs-485?
Jan 24 17:43:51 <bradfa> rs-485 less used around here
Jan 24 17:44:03 <bradfa> I have expresscard gigabit ethernet in laptop
Jan 24 17:44:04 <bradfa> it works OK
Jan 24 17:44:07 <bradfa> marvel chipset
Jan 24 17:44:07 <mdp> all the rage here
Jan 24 17:44:50 <mdp> I used one of the twin rs-232 expresscard units on a past laptop
Jan 24 17:45:25 <mdp> all this stuff works great when it's on a real bus, of course
Jan 24 17:45:46 <bradfa> http://www.exsys-shop.ch/shop/product_info.php?info=p5_Expansion-Box-PCI-Express-Slot-zu-4-x-PCI-Slots.html
Jan 24 17:45:49 <bradfa> want!
Jan 24 17:45:55 <bradfa> and a tape drive
Jan 24 17:46:18 <KotH> bradfa: didnt i say they have cool stuff :)
Jan 24 17:46:21 <mdp> everybody needs that
Jan 24 17:46:27 <bradfa> KotH, yes!
Jan 24 17:46:45 <mdp> bradfa, why doesn't Dell bundle these features? ;)
Jan 24 17:46:59 <bradfa> mdp, they are focused on the "enterprise cloud"
Jan 24 17:47:01 <bradfa> or something
Jan 24 17:47:18 <mdp> "Dell Inspiron PCIe/PCI expansion box bundle"
Jan 24 17:47:21 * bradfa goes to meeting...
Jan 24 17:47:34 <mdp> you had me at cloud
Jan 24 17:49:40 <CareBear\> aw
Jan 24 17:49:58 <CareBear\> everyone is in seventh heaven
Jan 24 18:02:04 <mrpackethead_> .
Jan 24 18:02:28 <mdp> ..
Jan 24 18:02:49 <mranostay> ...
Jan 24 18:06:08 <mru> ....
Jan 24 18:08:03 <emeb> .....
Jan 24 18:08:26 * djlewis ......
Jan 24 18:09:19 <mru> eish5<EILSEQ>
Jan 24 18:19:17 <mdp> *board killer: http://www.gizmosphere.org/why-gizmo/
Jan 24 18:20:27 <mrpackethead_> mdp: whats it goign to kill
Jan 24 18:20:50 <mdp> one must apply "killer" to all new board releases
Jan 24 18:20:58 <mdp> I don't know what it could kill
Jan 24 18:21:19 <crashovrd> if it has a heatsink, "you're doing it wrong!"
Jan 24 18:21:25 <crashovrd> think of the children!
Jan 24 18:21:42 <mdp> perhaps it's a child-killer then
Jan 24 18:22:00 <crashovrd> its more x86 eco terrorism!
Jan 24 18:22:59 <crashovrd> i got a laugh out of the Ouya dev kits.
Jan 24 18:23:09 <crashovrd> its a tegra3 arm soc
Jan 24 18:23:17 <crashovrd> with a HEATSINK!
Jan 24 18:23:59 <mru> I'm reminded of a couple of STBs I worked with a few years ago
Jan 24 18:24:05 <mru> both used the same bcm chip
Jan 24 18:24:25 <mru> one (by thomson) had no heatsink, the other (by lg) had a massive one
Jan 24 18:24:52 <mru> in the lg box the chip was hot enough to fry the breakfast bacon
Jan 24 18:25:05 <mru> the thomson one wasn't even slightly warm
Jan 24 18:25:17 <mru> and they ran the exact same software
Jan 24 18:25:20 <KotH> mru: did you ever figure out what made the difference?
Jan 24 18:25:37 <crashovrd> i would say its clock rate
Jan 24 18:25:43 <mru> the lg board must have set some output pin high and shorted it to ground
Jan 24 18:25:49 <mru> crashovrd: exactly the same
Jan 24 18:26:04 <mru> the boxes were supposed to have the exact same specs
Jan 24 18:26:12 <mru> directv multi-sourcing
Jan 24 18:26:34 <crashovrd> maybe one used the evil vendor tree
Jan 24 18:26:36 <florian> crashovrd: I decided not to like tegra when i first burned my fingers on a tegra at embedded world ;-)
Jan 24 18:26:45 <mru> crashovrd: not running linux
Jan 24 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
Jan 24 18:27:16 <mru> crashovrd: they ran exactly the same software
Jan 24 18:27:39 <crashovrd> maybe one was fabbed with dirt
Jan 24 18:27:42 <crashovrd> :)
Jan 24 18:27:43 <mrpackethead_> even my 80W leds don't run hot
Jan 24 18:28:12 <mranostay> 80W LEDS?
Jan 24 18:28:17 <mrpackethead_> yup
Jan 24 18:28:18 <mrpackethead_> 80W
Jan 24 18:28:27 <crashovrd> they can see your house from space
Jan 24 18:28:35 <mrpackethead_> cree makes them for street lights
Jan 24 18:29:44 <mrpackethead_> but they do have a heat sink.
Jan 24 18:30:08 <KotH> mrpackethead_: what's the efficiency of those leds?
Jan 24 18:31:04 <mrpackethead_> its qutie high, jsut looking
Jan 24 18:31:13 <KotH> must be
Jan 24 18:31:16 <koen> 80W is the incandescant power usage
Jan 24 18:31:26 <KotH> though, i thought that white leds have something around 80% or so
Jan 24 18:31:35 <koen> so "80W led" means "as bright as 80W bulb, uses on 4W"
Jan 24 18:31:41 <mrpackethead_> no.. its 80W of power
Jan 24 18:32:44 <mrpackethead_> cree web site is running like a dog
Jan 24 18:34:20 <mrpackethead_> 122 lm/W
Jan 24 18:34:58 <mrpackethead_> getting up to abotu 6000 lumens out of them
Jan 24 18:35:05 <mranostay> mru: so Nikon or Canon?
Jan 24 18:36:01 <mrpackethead_> geepers; thats like asking;   Macos or Windows, Nike or rebok..
Jan 24 18:36:40 <KotH> ubuntu! and adidas
Jan 24 18:36:58 <mru> mranostay: huh?
Jan 24 18:37:11 <mranostay> mru: camera choices
Jan 24 18:37:24 <mru> I'm partial to canon
Jan 24 18:37:37 <mru> but I hear nikon make some good stuff too
Jan 24 18:38:05 <KotH> mranostay: choose wisely, as it is a choice for life... and probably for your children and grand children as well :)
Jan 24 18:39:16 <koen> mru: Cree XM?
Jan 24 18:39:24 <mru> koen: huh?
Jan 24 18:39:36 <koen> cree uses similar names, coincidence
Jan 24 18:46:56 <mru> koen: what's that got to do with me?
Jan 24 18:47:46 <Crofton|work> mru, will you be at FOSDEM?
Jan 24 18:47:56 <koen> ah
Jan 24 18:48:05 <koen> s/mru/mrpackethead/
Jan 24 18:57:08 <jsabeaudry> How to instanciate virtual i2c busses from sysfs?
Jan 24 19:03:12 <KotH> .o0(sie mόssen nur den nippel durch die lasche ziehn....)
Jan 24 19:06:27 <woglinde> koth dont steal from us
Jan 24 19:08:04 <KotH> woglinde: ?
Jan 24 19:20:11 <mrpackethead_> im looking at pin muxing
Jan 24 19:20:23 <mrpackethead_> geepers its exciting.. not
Jan 24 19:34:07 <prpplague> koen: hey, you know if the wifi caps are done?
Jan 24 19:39:21 <mranostay> wifi caps?
Jan 24 19:41:05 <mrpackethead_> Somethign you put on a trolls head to connect them when you move?
Jan 24 19:41:29 <ds2> hmmm
Jan 24 19:50:34 <mrpackethead_> is there any concept of remappable pin functions in teh AM3559
Jan 24 19:50:50 <mrpackethead_> i know you can choose between the functions of the pins
Jan 24 19:51:32 <_av500_> sure
Jan 24 19:51:50 <_av500_> the chip lets you remap pins any time
Jan 24 19:52:24 <mrpackethead_> but only the functions that are on that pin.
Jan 24 19:53:00 <mrpackethead_> GPIO2_28 for example appears on pin G15
Jan 24 19:53:15 <mrpackethead_> i cna't remap that somehow to F18
Jan 24 19:53:22 <mrpackethead_> GPIO is not a great example
Jan 24 19:54:18 <mrpackethead_> PRUETH1_RXCLK appears on U16..
Jan 24 19:54:28 <mrpackethead_> U16 is Not connected on the beaglebone.
Jan 24 19:54:45 <mrpackethead_> some chipsets can map betweeen pins
Jan 24 19:55:44 <mdp> the full capability of the pinmux is detailed in the datasheet..that's it.
Jan 24 19:56:15 <mrpackethead_> yup.. thats the way that i read it
Jan 24 19:56:29 <mrpackethead_> i just wanted to make sure that i had'nt missed any magic
Jan 24 19:57:03 <mdp> you have not missed anything
Jan 24 19:57:25 <mrpackethead_> there are five pins i can not access
Jan 24 19:57:27 <mrpackethead_> :-(
Jan 24 19:58:14 <mrpackethead_> jkridner_: are you about
Jan 24 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
Jan 24 19:58:51 <mrpackethead_> absolteuly.
Jan 24 19:59:13 <mrpackethead_> its not the end of the world though mdp
Jan 24 19:59:20 <mrpackethead_> there are ways and means
Jan 24 19:59:21 <mdp> e.g. for one project, I need 8 uarts..and it totally fails me
Jan 24 19:59:22 <mrpackethead_> :-)
Jan 24 19:59:22 <mdp> ;)
Jan 24 19:59:48 <mdp> mrpackethead_: right, it's just another arm part, the world will not miss one arm part
Jan 24 19:59:54 <mrpackethead_> use the UARTS and the PRU's? ( some soft UARTS )
Jan 24 20:00:22 <mdp> yeah, it is an option
Jan 24 20:00:31 <mrpackethead_> there you go, its not failed you.
Jan 24 20:00:53 <mrpackethead_> problem shared, problem havlved..
Jan 24 20:00:54 <mrpackethead_> lol.
Jan 24 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
Jan 24 20:01:08 <mdp> s/you the/using the/
Jan 24 20:01:14 <mrpackethead_> yup.
Jan 24 20:01:25 <mdp> anyway, always tradeoffs ;)
Jan 24 20:01:43 <mrpackethead_> I want to implement Profinet and Ethercat under Linux
Jan 24 20:02:02 <mrpackethead_> The TI folks have got the 'ICE' board
Jan 24 20:02:45 <mrpackethead_> its got Ethercat/Profinet..  but it runs their RTOS system
Jan 24 20:02:54 <mrpackethead_> getting all the other code to run under that would be a nightmare
Jan 24 20:03:21 <mrpackethead_> moving the ethercat to linux is much less work.
Jan 24 20:03:32 <mrpackethead_> however you need to use the PRU_MII ports
Jan 24 20:03:35 <ds2> you could always slap on 8 TUSB chips ;)
Jan 24 20:04:35 <mrpackethead_> sadly, 5 of the 28 required pins are not on the headers
Jan 24 20:04:50 <mrpackethead_> but i am not giving up
Jan 24 20:07:13 <mdp> ds2, ok, now stop that! ;)
Jan 24 20:08:08 <mdp> mrpackethead_: what headers..are you talking about bone now?
Jan 24 20:08:18 <mrpackethead_> yes, bone.
Jan 24 20:09:10 <mrpackethead_> there is enough pins to implemnet a single port
Jan 24 20:09:16 <mdp> spin your own derivative?
Jan 24 20:09:26 <mrpackethead_> i'm thinking about that
Jan 24 20:09:48 <mrpackethead_> the easiest way is simply to add another layer to the pcb
Jan 24 20:13:51 <mrpackethead_> jkridner_ suggested yesterday that it may be possible in a future revsiosn to get to the pins.
Jan 24 20:14:01 <mrpackethead_> they have joined some pins togehter already.
Jan 24 20:14:16 <jkridner_> about
Jan 24 20:14:21 <mrpackethead_> hello.
Jan 24 20:14:45 <mrpackethead_> jkridner_: just following though on our dicsusion yesterday about Pin avaialblily
Jan 24 20:14:57 <djlewis> back in the day, on beaglebone, we asked for the camera pins to be revealed and later they were :)
Jan 24 20:15:26 <mrpackethead_> i worked on establihsing which additinal pins i needed to see
Jan 24 20:15:30 <djlewis> beagleboard
Jan 24 20:15:36 <mrpackethead_> and theres 5
Jan 24 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.
Jan 24 20:16:21 <ds2> hahahahah
Jan 24 20:16:23 * mranostay reports jkridner_ to HR
Jan 24 20:16:31 <mdp> ds2, I misread that too ;)
Jan 24 20:16:40 <jkridner_> lol
Jan 24 20:17:07 <mdp> summary, "grow a pair and send an email!"
Jan 24 20:17:10 <ds2> should a box of chocolates be included?
Jan 24 20:17:39 <mranostay> roses i'd go for roses
Jan 24 20:17:45 <mrpackethead_> roses suck
Jan 24 20:19:11 <ds2> is there another P/N for a am335x pin compatible device w/o ethernet?
Jan 24 20:19:32 <mrpackethead_> jkridner_: would i be right in assuming that if you join the pins together
Jan 24 20:19:59 <mrpackethead_> and you effetively loose the functionality of the other pin.
Jan 24 20:20:22 <mrpackethead_> or better to say;
Jan 24 20:20:53 <mrpackethead_> you can then choose 1 pin function out of the set of all the functions of the joined pins
Jan 24 20:21:14 <jkridner_> yeah, the other ball/pin would need to be disabled to use the new function.
Jan 24 20:21:35 <mrpackethead_> mmm
Jan 24 20:22:04 <mrpackethead_> the other thing of course, is that i've then pulled 26 pins away from other thigns
Jan 24 20:22:19 <mrpackethead_> some of which i may well want to use :-)
Jan 24 20:30:03 <koen> prpplague: afaik they are still not in
Jan 24 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.
Jan 24 20:36:39 <mrpackethead_> yes, i am writing an email about Balls to Gerald right now :-)
Jan 24 20:37:08 <panto> goodnight ppl
Jan 24 20:37:52 <jkridner_> koen: did you see Gerald's issue with having no display output?
Jan 24 20:38:15 <mrpackethead_> http://pastebin.com/zhpGaVj0  <-- this is the required pins
Jan 24 20:38:58 <mrpackethead_> the formatting didtn work so well
Jan 24 20:39:57 <mrpackethead_> as you can see there is enough pins to get PRUETH0 working
Jan 24 20:41:22 <koen> jkridner_: yes
Jan 24 20:41:38 <koen> jkridner_: I dumped the card that was in my board, which does output something onthe screen
Jan 24 20:41:47 <koen> jkridner_: so I don't know what's happening
Jan 24 20:42:26 <jkridner_> k. :( hopefully robclark will have an idea.
Jan 24 20:42:47 <mrpackethead_> ok.. Sent the balls
Jan 24 20:42:49 <mrpackethead_> :-)
Jan 24 20:42:54 <jkridner_> mrpackethead_: which column is what?
Jan 24 20:43:05 <robclark> jkridner_, still not getting display?
Jan 24 20:43:28 <jkridner_> intermittent per boot. Gerald didn't get any when he tried.
Jan 24 20:43:30 <mrpackethead_> first two colums are teh Ball id's
Jan 24 20:43:45 <mrpackethead_> for the PRUETH functions
Jan 24 20:43:47 <robclark> hmm
Jan 24 20:44:15 <XorA> sounds like my beagleXM will only display on my monitor approx 1/20 boots :-(
Jan 24 20:44:16 <mrpackethead_> first colum is for eth0, 2nd for eth1
Jan 24 20:44:19 <robclark> jkridner_, could you put your uImage (and DT) somewhere?
Jan 24 20:44:39 <mrpackethead_> forth colum and fifth colums are where those functions appear on P8/P9 now
Jan 24 20:45:14 <mrpackethead_> T2, V4, T5, V3 and T13 anre the missing balls
Jan 24 20:48:04 <jkridner_> what is the 3rd column?
Jan 24 20:48:14 <jkridner_> signal names?
Jan 24 20:48:22 <jkridner_> for the MII?
Jan 24 20:49:00 <jkridner_> based on column 4, it looks like you have what you need brought to the headers for PRUETH0
Jan 24 20:50:06 <mrpackethead_> yes, PRUETH0 is compelte
Jan 24 20:50:29 <mrpackethead_> its PRUETH1 that is problematic
Jan 24 20:50:40 <jkridner_> USR0/1/2/3 will be driven 99.99% of the time.
Jan 24 20:50:52 <jkridner_> they are consumed for the LEDs, so they aren't N/C
Jan 24 20:51:01 <mrpackethead_> yes.
Jan 24 20:51:14 <jkridner_> The only ones that are an option to bring to the headers are ones that are currently N/C
Jan 24 20:51:34 <mrpackethead_> the USR0/1/2/3 are though already on the headers
Jan 24 20:51:58 <jkridner_> where?
Jan 24 20:52:17 <jkridner_> why didn't you give the header pin name you wanted the signals connected to?
Jan 24 20:54:41 <mrpackethead_> jkridner_: opps
Jan 24 20:54:45 <mrpackethead_> you are right
Jan 24 20:55:01 <mrpackethead_> all of those functiosn are not there
Jan 24 20:55:25 <mrpackethead_> grrr.
Jan 24 20:55:32 <mrpackethead_> i've misread that
Jan 24 20:56:34 <mrpackethead_> never mind.
Jan 24 21:01:09 <mrpackethead_> its forward progress.
Jan 24 21:01:15 <mrpackethead_> establing what cna't be done is useful
Jan 24 21:03:23 <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.
Jan 24 21:03:24 <mrpackethead_> Gerald
Jan 24 21:03:43 <mrpackethead_> well thats that
Jan 24 21:03:51 <woglinde> poor hobbit
Jan 24 21:04:04 <mrpackethead_> no hobit is not upset
Jan 24 21:04:18 <mrpackethead_> hobbit knows that often finding the solution is about findign out what are not the solutiosn
Jan 24 21:05:14 <Crofton|work> finding solution by process of elimination
Jan 24 21:05:28 <mrpackethead_> if you dont' consider options
Jan 24 21:05:42 <mrpackethead_> how can you be resonably sure that you've though it through.
Jan 24 21:45:52 <jsabeaudry> How can I disable musb?
Jan 24 21:47:57 <jsabeaudry> Comment all *MUSB* in my .config?
Jan 24 21:49:07 <jsabeaudry> Will it break my serial console?
Jan 24 21:49:58 <mranostay> jsabeaudry: nousb in uEnv.txt is what i do
Jan 24 21:52:54 <jsabeaudry> mranostay, thank you that is even simpler
Jan 24 21:58:55 <mdp> mranostay, we're lobbying for derivative with PM and USB removed.
Jan 24 21:59:19 <mdp> mranostay, AM33Eleven
Jan 24 21:59:37 <ds2> bah
Jan 24 21:59:40 <ds2> remove ethernet!
Jan 24 21:59:50 <ds2> put the 37xx PM in there
Jan 24 22:00:05 <Jacmet> wee, laptop survived bios upgrade ;)
Jan 24 22:00:06 <mdp> then you'll want DSS
Jan 24 22:00:16 <mdp> ds2, where does the madness stop?
Jan 24 22:00:17 <ds2> DSS is optional
Jan 24 22:00:28 <mrpackethead_> what is DSS?
Jan 24 22:00:30 <ds2> mdp: I just don't see that much use for having the ethernet there
Jan 24 22:00:46 <ds2> the 33x display stuff is just fine
Jan 24 22:00:51 <mdp> some people like it
Jan 24 22:01:10 <mdp> if the driver worked they'd like it better, but it looks good on the datasheet
Jan 24 22:01:17 <Jacmet> mdp: ;)
Jan 24 22:01:21 <ds2> ethernet burns power
Jan 24 22:01:40 <mdp> PCIe would solve everything ;)
Jan 24 22:01:51 <mdp> we could forget about all this capemgr stuff
Jan 24 22:01:52 <ds2> ARRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGGGGG
Jan 24 22:01:55 <mdp> ;)
Jan 24 22:01:59 * ds2 runs screaming
Jan 24 22:02:18 * mdp tries all the buttons and pushes the correct one for ds2.
Jan 24 22:02:23 <mrpackethead_> ethernet means you can talk to the world.
Jan 24 22:02:43 <ds2> you can say the same about smoke signals
Jan 24 22:02:44 <mdp> mrpackethead_: it's wired, that's so 90s
Jan 24 22:03:11 <ds2> and I'd be more inclined to go with the 3507
Jan 24 22:03:47 <ds2> proven davinci emac
Jan 24 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
Jan 24 22:05:52 <ds2> maybe that is a spare one for manufacturing
Jan 24 22:06:25 <Jacmet> ds2 that part of the control module seems identical to the am335x one
Jan 24 22:07:31 <mdp> Jacmet: I wonder why people propagated "EMAC" in 81xx wiki docs and such..since it's cpsw
Jan 24 22:08:00 <Jacmet> mdp: ehh, isn't it only cpsw on 814x?
Jan 24 22:08:08 <ds2> but it is more fun to introducea whole new alphabet soup
Jan 24 22:08:16 <Jacmet> TI is good at that
Jan 24 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
Jan 24 22:13:42 <ds2> Jacmet: does u-boot say it is a davinci emac?
Jan 24 22:14:23 <mdp> Jacmet: I read 814x here ;) that's the one I usually play with
Jan 24 22:14:44 <mdp> but 816x does have two of the modified emacs
Jan 24 22:14:57 <mdp> what was that about one?
Jan 24 22:15:45 <mdp> by modified, I mean it does gmii too unlike the old omapl versions
Jan 24 22:17:06 <Jacmet> ds2: I don't have the board here, but I believe so
Jan 24 22:18:59 <Jacmet> mdp: sorry, I mixed up with another device
Jan 24 22:21:08 <mdp> it hurts my brain to remember what is what on these things
Jan 24 22:21:38 <mdp> EMAC driver is at least a little more mature
Jan 24 22:22:05 <Jacmet> mdp: you're not the only one
Jan 24 22:22:38 <Jacmet> mdp: mature as in the evil ancient 81xx vendor kernel? ;)
Jan 24 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 ;)
Jan 24 22:23:06 <mru> mdp: how about the emacs driver?
Jan 24 22:23:10 <mdp> Jacmet: I mean on the upstream stuff
Jan 24 22:23:40 <mdp> mru, I use a emacs driver wrapper around vim
Jan 24 22:23:50 <Jacmet> mdp: ok, there's unfortunately very little 81xx stuff upstream (besides the stuff shared with other devices)
Jan 24 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
Jan 24 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
Jan 24 22:24:39 <mdp> that's the only use I have for 81xx ;)
Jan 24 22:25:13 <Jacmet> mdp: I'm stuck with a 8168 here mainly for political reasons
Jan 24 22:25:35 <mdp> Jacmet: yeah, he's popped up a couple times about that...we chatted at plumbers the other year about it
Jan 24 22:25:53 <mdp> Jacmet: somebody hates you there?
Jan 24 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
Jan 24 22:26:34 <Jacmet> mdp: something like that
Jan 24 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
Jan 24 22:28:02 <Jacmet> mdp: I think 814x seems a better bet than 816x
Jan 24 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
Jan 24 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
Jan 24 22:28:56 <mdp> either one has the IP I need to work on
Jan 24 22:29:01 <Jacmet> mdp: yes, remember the mail. As far as I remember, that was back in sep/oct
Jan 24 22:29:25 <mdp> maybe that completed some of the puzzle he wasn't yet at
Jan 24 22:29:36 <Jacmet> mdp: is there anything funky about the pcie? I heard rumours about stability issues on 816x
Jan 24 22:30:02 <mdp> if he didn't need spi, mmc, etc. then maybe wasn't initially important
Jan 24 22:30:22 <mdp> Jacmet: I'm still coming up to speed...been sifting through tremendous errata
Jan 24 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
Jan 24 22:30:50 <mdp> it's all unclear to me if the s/w folks involved had any prior pci experience
Jan 24 22:30:54 <mdp> but that's another story
Jan 24 22:31:03 <mdp> yeah, me too
Jan 24 22:31:14 <mdp> PCIe is important on these new parts
Jan 24 22:31:26 <mdp> like the J6 they just announced..hence my interest
Jan 24 22:31:26 <Jacmet> mdp: I'm definately interested if something happens on mainline side for 81xx
Jan 24 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
Jan 24 22:32:18 <Jacmet> mdp: J6?
Jan 24 22:32:22 <mdp> other than that, I have to admit, it would be ok if 81xx fell of the end of the earth ;)
Jan 24 22:32:35 <mdp> jacinto 6
Jan 24 22:32:52 <Jacmet> mdp: yeah, me too, but seems I'm stuck with it for now
Jan 24 22:33:06 <mdp> yeah, me too..it's all I've got
Jan 24 22:33:15 <mdp> I'll give you a heads up as I get into it
Jan 24 22:33:27 <mdp> should help with what you are doing
Jan 24 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 ;)
Jan 24 22:34:19 <Jacmet> mdp: thanks
Jan 24 22:34:21 <Jacmet> and heh
Jan 24 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. ;)
Jan 24 22:36:49 <mdp> pay now or pay later
Jan 24 22:38:12 <Jacmet> mdp: yes, as I'm moving from am33xx to 81xx a lot of it seems very familiar
Jan 24 22:39:20 * Jacmet ponders if the J6 means that there's a 81xx replacement coming up .. 
Jan 24 22:40:13 <mdp> J6 is pretty much just automotive markets if you follow the PR and marketing positioning
Jan 24 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
Jan 24 22:42:26 <mdp> J6 is weird, take a look at the block diagram
Jan 24 22:42:52 <mdp> they call it OMAP(tm) and that tells you it comes from that org
Jan 24 22:43:08 <ds2> uh...
Jan 24 22:43:16 <ds2> OMAP3530 ;)
Jan 24 22:43:24 <mdp> ok, always exceptions
Jan 24 22:43:28 <mdp> but these days...
Jan 24 22:43:32 <ds2> :D
Jan 24 22:43:51 <mdp> always exceptions with TI naming..that's the rule.
Jan 24 22:43:56 <ds2> isn't that a dead man walking name? ;)
Jan 24 22:44:08 <mdp> Jacmet: http://www.ti.com/product/dra746?DCMP=omap-jac6-130107&HQS=omap-jac6-pr-pf
Jan 24 22:45:01 <mdp> notice it has both SDMA and EDMA on it ;)
Jan 24 22:45:29 <mru> and CDMA?
Jan 24 22:45:44 <mdp> mru, yes, going after the .us market with that
Jan 24 22:45:47 <mdp> very important
Jan 24 22:45:52 <mdp> and SUV support
Jan 24 22:45:54 <Jacmet> mdp: yeah. Single ivahd?
Jan 24 22:45:59 <ds2> no WCDMA?
Jan 24 22:46:06 <mru> HDMA?
Jan 24 22:46:23 <mdp> ds2, if you ask marketing, it's got whatever you need
Jan 24 22:46:33 <mdp> including QNX
Jan 24 22:46:54 <ds2> I have long decided that I don't ask marketing anything :D
Jan 24 22:47:13 <mdp> ds2, it can be played as a drinking game.
Jan 24 22:48:11 <mdp> Jacmet: but in any case, note the PCIe Gen 2 there.
Jan 24 22:48:19 <mdp> Pizza:30, bbl
Jan 24 22:48:27 <mranostay> life is a drinking game :)
Jan 24 22:48:28 <Jacmet> mdp: yes, like ti81xx
Jan 24 22:48:42 <mru> what mranostay said
Jan 24 22:56:33 <Jacmet> mdp: besides pcie, are there mainline plans for J6?
Jan 24 23:31:44 <mranostay> Jacmet: "patches are welcome" is the mainine plans probably :P
Jan 25 01:14:24 <spacecolonyone> hey guys does anyone know offhand if the angstrom/systemd bb image is using initramfs
Jan 25 01:15:59 <mranostay> magic?
Jan 25 01:16:16 <mranostay> probably depends on the image you build
Jan 25 01:16:33 <mranostay> but the 'default' one is no
Jan 25 01:17:03 <spacecolonyone> ok angstrom 2012.05 systemd base image
Jan 25 01:28:24 <mdp> Jacmet: the plan is "everything", my parts are dust specs in the larger effort
Jan 25 02:01:43 <mranostay> hi emeb_mac
Jan 25 02:01:45 <mranostay> and prpplague
Jan 25 02:02:01 <emeb_mac> hi mranostay
Jan 25 02:02:10 <emeb_mac> and prpplague :)
Jan 25 02:02:23 <prpplague> greetings all
Jan 25 02:02:48 <mranostay> do people actaully like people? :)
Jan 25 02:02:49 <emeb_mac> oh btw - latest little board: http://ebrombaugh.studionebula.com/embedded/stm32f303breakout/index.html
Jan 25 02:02:56 * mranostay is having one of those days
Jan 25 02:03:14 <emeb_mac> for days like that there are cats.
Jan 25 02:03:31 <mranostay> i'm giving that furball an extra hug when i get home :P
Jan 25 02:04:56 <mranostay> prpplague: TIL there is no jumper cables in this entire company... :)
Jan 25 02:05:05 <prpplague> hehe
Jan 25 02:05:19 <emeb_mac> dead battery in the parking lot and no one would help?
Jan 25 02:05:19 <prpplague> mranostay: i keep two pair in my car at all times
Jan 25 02:05:29 <mranostay> prpplague: not those kind :)
Jan 25 02:05:58 <prpplague> mranostay: ??
Jan 25 02:06:04 <emeb_mac> what other kind are there?
Jan 25 02:06:10 <mru> you can keep any kind in the car
Jan 25 02:06:24 <mranostay> the breadboard kind
Jan 25 02:06:44 <mru> remind me some time to tell a joke about keeping something in the car
Jan 25 02:06:52 <mranostay> how about now?
Jan 25 02:06:57 <mru> this ain't the place
Jan 25 02:07:08 * mranostay makes note for ELC
Jan 25 02:08:12 <prpplague> mranostay: ahh
Jan 25 02:08:21 <prpplague> mranostay: indeed TI offices are the same way
Jan 25 02:08:45 <mru> mranostay: what's special about breadboards?
Jan 25 02:09:11 * mru always uses plain wire of a suitable gauge
Jan 25 02:09:45 <mranostay> well i need to use it test a RS-232 pinout
Jan 25 02:09:54 <prpplague> mranostay: real solder their projects on protoboards
Jan 25 02:10:05 <prpplague> mranostay: real MEN solder their projects on protoboards
Jan 25 02:10:11 * mranostay works for cheap ass company
Jan 25 02:10:25 <mranostay> heh
Jan 25 02:10:29 <mru> prpplague: we all know mranostay is but a kid, a far cry from a real man
Jan 25 02:10:31 <mranostay> just a RS-232 cable
Jan 25 02:10:48 <mranostay> or RJ-45 to DB-9 adapter
Jan 25 02:11:02 <mranostay> mru: cute
Jan 25 02:11:23 <mru> mranostay: no, you're too old to be 'cute'
Jan 25 02:11:51 <mranostay> so i'm at the awkward age?
Jan 25 02:12:16 * emeb_mac has been at the awkward age for some time now
Jan 25 02:12:34 <Russ> mranostay, it would have been nice if all db-9's were replaced with yost long ago
Jan 25 02:14:02 <emeb_mac> should have made the whole world switch to the Apple DIN-8 style serial cables. :P
Jan 25 02:14:10 * Russ looks at emeb_mac's mini-usb connector
Jan 25 02:14:22 <emeb_mac> Russ: you like that?
Jan 25 02:14:37 <Russ> why have 5 pins when you only need 3, eh?
Jan 25 02:14:41 <emeb_mac> solid as a rock - no way that's tearing off like those SMD ones
Jan 25 02:14:47 <emeb_mac> the other two are underneath
Jan 25 02:15:01 <emeb_mac> zig-zag pattern
Jan 25 02:15:11 <Russ> it helps for smd if you put a via or two in
Jan 25 02:16:09 <emeb_mac> yes, but most don't have any PTH at all
Jan 25 02:17:22 <mranostay> well only 3 are used today right?
Jan 25 02:17:27 <mranostay> nobody does HW flow
Jan 25 02:17:36 <Russ> (we were talking usb)
Jan 25 02:17:43 <mranostay> ah ok :)
Jan 25 02:17:54 <Russ> rts/cts are nice to have
Jan 25 02:18:45 <Russ> and dcd/dtr is nice if you have a serial terminal with login, so it can log out automatically
Jan 25 02:18:50 <mrpackethead_> im actualy working on my via builder right now
Jan 25 02:19:08 <emeb_mac> via builder?
Jan 25 02:19:47 <mrpackethead_> yup.. a beagle thats helping buidling capes
Jan 25 02:19:59 <mrpackethead_> which came first the cape or the beagle
Jan 25 02:20:52 <mrpackethead_>  im building a Electroplater
Jan 25 02:22:07 <mranostay> mru: they move your talk time?
Jan 25 02:23:00 <spacecolonyone> koen: did I miss an upgrade from connman 0.79 to 1.10
Jan 25 02:23:06 <mru> mranostay: so it seems
Jan 25 02:23:19 <Russ> damn, I already made my schedule, lunch and breaks included
Jan 25 02:23:52 <mranostay> no more conflict in that slot
Jan 25 02:24:01 <Russ> what was his old slot?
Jan 25 02:24:10 <mru> the one after
Jan 25 02:24:27 <mrpackethead_> cat 1 > run
Jan 25 02:24:54 <mranostay> ah this is not a shell
Jan 25 02:24:57 <Russ> it used to be at 5?
Jan 25 02:25:14 <mrpackethead_> sorry
Jan 25 02:25:16 <mrpackethead_> wrong window
Jan 25 02:25:33 <Russ> just be sure to type something more interesting, next time, ok?
Jan 25 02:26:01 <mru> passwords and credit card numbers are preferred
Jan 25 02:26:12 <mru> especially if they match
Jan 25 02:26:27 <mranostay> expiration date as well
Jan 25 02:27:03 <mru> do you usians have the extra password thing on your credit cards?
Jan 25 02:27:11 <mrpackethead_> 378282246310005
Jan 25 02:27:23 <mrpackethead_> 4012888888881881
Jan 25 02:27:49 <mru> first one looks plausibly like an amex number
Jan 25 02:27:52 <mrpackethead_> 	5105105105105100
Jan 25 02:28:11 <mrpackethead_> they will pass sanity checks
Jan 25 02:28:14 <mrpackethead_> but won't do much else
Jan 25 02:28:16 <mrpackethead_> :-)
Jan 25 02:29:43 <mrpackethead_> hi rcn-ee
Jan 25 02:30:39 <rcn-ee> hi mrpackethead_ , what's up..
Jan 25 02:31:14 <mrpackethead_>  rcn-ee: just working on PWM stuff on a beagle under debian
Jan 25 02:31:45 <rcn-ee> ah fun, isn't there a brand new kernel driver for that under v3.8-rc's? ;)
Jan 25 02:32:06 <mrpackethead_> you might know, and this might be a silly quesiton..  Why is  /sys/kernel/debug/ not mounted by default?
Jan 25 02:33:22 <rcn-ee> By default, i haven't stuck anything else in /etc/fstab other then proc and the two mount points. ;)
Jan 25 02:33:34 <mrpackethead_> right..
Jan 25 02:34:04 <mrpackethead_> any reason not to add it into /etc/fstab?
Jan 25 02:34:06 <rcn-ee> i'm pretty sure we could drop proc, do you guys want me to stick it in their by default? would be a one liner in the script..
Jan 25 02:35:34 <mrpackethead_> it die'snt make much difference to me
Jan 25 02:35:45 <mrpackethead_> i was just wondering if there was a reason for it
Jan 25 02:36:02 <rcn-ee> oh, just never bothered. ;)
Jan 25 02:36:07 <rcn-ee> and no one asked. ;)
Jan 25 02:36:21 <mranostay> http://www.businessinsider.com/eric-schmidt-wrote-the-most-hilariously-self-defeating-email-you-will-ever-read-2013-1 <--- how dumb is that? :)
Jan 25 02:36:54 <mrpackethead_> how do people do pin mapping etc , if its not mounted?
Jan 25 02:37:11 <mranostay> eh?
Jan 25 02:38:38 <rcn-ee> oh they mount it. ;)
Jan 25 02:38:49 <mrpackethead_> ok, like what i've done
Jan 25 02:41:29 <Russ> mranostay, looking at one of the linked articles
Jan 25 02:41:31 <Russ> http://www.businessinsider.com/my-micro-ny-wins-adapt-nyc-competition-2013-1
Jan 25 02:41:34 <Russ> I like the picture
Jan 25 02:41:47 <mrpackethead_> talking of compettions
Jan 25 02:41:52 <mrpackethead_> hows cape-comp going
Jan 25 02:42:18 <Russ> mranostay, reminds me of this http://boingboing.net/wp-content/uploads/2011/07/whale-fail-pool.jpg
Jan 25 02:44:21 <mrpackethead_> rcn-ee: Does the LCD-Cape ( LCD-3 ) work with the debian build?
Jan 25 02:44:41 <mranostay> eh
Jan 25 02:44:43 <rcn-ee> mrpackethead_, just pushed it out.. https://github.com/RobertCNelson/omap-image-builder/commit/fbbb9e3c38af79f90dec2cc839c4e01d44592d6b
Jan 25 02:44:56 <mranostay> Russ: hobbits?!
Jan 25 02:45:08 <Russ> I think so
Jan 25 02:45:22 <rcn-ee> it does with v3.2.x, with the demo images, i have this startup hack: https://github.com/RobertCNelson/tools/blob/master/target/BeagleBone.sh
Jan 25 02:45:50 <rcn-ee> with v3.6/v3.7/v3.8 i haven't got it to work yet..
Jan 25 02:46:19 <mrpackethead_> im fine with 3.2.33 righ tnow
Jan 25 02:46:30 <mrpackethead_> no need to be cutting edge like the trolls
Jan 25 02:47:08 <rcn-ee> i look at it the other way...  v3.8.x has less patches to maintain then v3.2.x. ;)
Jan 25 02:48:00 <mrpackethead_> true.
Jan 25 02:48:12 <mrpackethead_> i'll move when its time.
Jan 25 02:48:13 <mrpackethead_> :-)
Jan 25 02:48:40 <rcn-ee> and right now, it's not ready..  atleast usb host now works... reset was still iffy today when i tried it..
Jan 25 02:49:26 <mrpackethead_> rcn-ee: do you think it woudl be possible to get debian to run on the TI ICE board?
Jan 25 02:50:57 <rcn-ee> it should actually work, as all the am335's share the same u-boot and kernel...
Jan 25 02:51:21 <rcn-ee> i've just never picked one up to test.. (although it's been in my shopping cart a few times.. just never pulled the trigger)
Jan 25 02:52:29 <mrpackethead_> i have one sitting in front of me
Jan 25 02:52:47 <mrpackethead_> the reason for the interest is the ethercat
Jan 25 02:56:35 <oodi> My BeagleBone outputs garbled text on the USB serial console when trying to install Debian. The kernel boot messages are properly displayed and readable. But the text based netinstall interface displays garbage. How can I fix that?
Jan 25 02:58:02 <rcn-ee> garbage? sounds like a usb/serial issue.. which serial terminal are you using?
Jan 25 02:58:16 <oodi> screen on OS X
Jan 25 02:59:04 <oodi> This is an example of what it shows: Tβ€β‹βŽ½ └▒≀ β”œβ–’β”βŠ βŽ½βŽΊβ””βŠ β”œβ‹β””βŠ.
Jan 25 02:59:42 <oodi> But if I fire up screen fast enough, I can see the kernel messages scroll by just fine.
**** ENDING LOGGING AT Fri Jan 25 02:59:58 2013