**** BEGIN LOGGING AT Wed Oct 24 03:00:02 2012
Oct 24 03:06:38 <joelagnel-home> koen: I guess README.md @ https://github.com/beagleboard/kernel/blob/3.7/README.md , should be updated? :)
Oct 24 06:41:00 <mranostay> hi emeb_mac
Oct 24 06:41:12 <emeb_mac> hi mranostay
Oct 24 06:43:14 <mranostay> emeb_mac: i forget are you making it to E-ELC?
Oct 24 06:43:52 <emeb_mac> mranostay: no, not coming to E-ELC.
Oct 24 06:44:01 <emeb_mac> Where is it this year?
Oct 24 06:44:17 <koen> barcelona, spain
Oct 24 06:46:02 <emeb_mac> ooh - sounds nice.
Oct 24 06:46:12 <mranostay> yeah it should be
Oct 24 06:46:16 <emeb_mac> Check out all the Gaudi architecture.
Oct 24 06:47:30 <mranostay> heh old photos --> http://elinux.org/ELCE_2012_Technical_Showcase
Oct 24 06:47:39 <mranostay> i haven't seen a CRT in years
Oct 24 07:19:54 <mranostay> _av500_: more sunrises!
Oct 24 07:20:42 <woglinde> no
Oct 24 07:20:46 <woglinde> its dark
Oct 24 07:20:57 <mranostay> yes but not in Germany!!!
Oct 24 07:21:52 <mranostay> homeland of 75% of my heritage :P
Oct 24 07:22:16 <mranostay> basically everyone just not my last name :)
Oct 24 07:22:23 <woglinde> o.O
Oct 24 07:22:35 <woglinde> yeah comeback
Oct 24 07:23:17 <mranostay> O.o
Oct 24 07:23:24 <woglinde> *g*
Oct 24 07:23:44 <mranostay> why does every damn photo upload from a iPhone have "edited" on it?
Oct 24 07:24:48 <woglinde> dont use an iphone
Oct 24 07:25:02 <mranostay> sure beats the driod
Oct 24 07:25:07 <mranostay> *droid
Oct 24 07:25:22 <woglinde> hm in accessing the filesystem without locked tools?
Oct 24 07:25:42 <LetoThe2nd> its because steve jobs ghost in the shell secretly edits all the posted photos from iAplle things ;)
Oct 24 07:25:51 <woglinde> leto *g*
Oct 24 07:26:26 <LetoThe2nd> howdy woglinde
Oct 24 07:26:56 <mranostay> i just want my phone to work :)
Oct 24 07:27:06 <mranostay> and apps that don't crash...
Oct 24 07:27:39 <LetoThe2nd> everyone gets what he wants, or rather deserves, er even more rather is willing to pay for ;)
Oct 24 07:28:11 <woglinde> yes
Oct 24 07:28:17 <woglinde> paying for editing is nice
Oct 24 07:28:31 <woglinde> paying for tiles which you can not turn off too
Oct 24 07:28:43 <LetoThe2nd> well at least on my devices i am as an adult allowed to pay for adult etertainment :=
Oct 24 07:29:10 <woglinde> ah right boobies are bad in all of the world not us only
Oct 24 07:29:24 * LetoThe2nd loves pointless violence and meaningless destruction of material values.
Oct 24 07:29:42 <LetoThe2nd> add some babes and it makes a perfect movie :)
Oct 24 07:30:40 <mranostay> why woud i want to view p0rn on a mobile device? :)
Oct 24 07:31:33 <LetoThe2nd> mranostay: here in germany pr0n has only lately been legally classified as travelling goods. :)
Oct 24 07:31:38 <mranostay> at that point i'm checking into SA :)
Oct 24 07:32:12 <LetoThe2nd> plus, when did i ever talk about pr0n? ;) reread my postings ;)
Oct 24 07:32:56 <mranostay>  LetoThe2nd> well at least on my devices i am as an adult allowed to pay for adult etertainment :=
Oct 24 07:33:04 <mranostay> which is? :-)
Oct 24 07:33:19 <LetoThe2nd> -> 09:29  * LetoThe2nd loves pointless violence and meaningless destruction of material values.
Oct 24 07:33:30 <mranostay> #beagle after dark in most timezones :)
Oct 24 07:33:56 <LetoThe2nd> mranostay: blade in the original cut for example is considered adult entertainment in most civilized countries ;)
Oct 24 07:35:19 <mranostay> LetoThe2nd: i think Twilight should be there instead :)
Oct 24 07:35:32 <LetoThe2nd> mranostay: considerably yes.
Oct 24 07:35:38 * mranostay got dragged to one of those films
Oct 24 07:35:49 <mranostay> New Moon iirc. don't really matter which crappy one :)
Oct 24 07:36:07 <LetoThe2nd> though i find it pretty amusing that especially americans always think i am talking of pr0n when i say "adult entertainment" ;)
Oct 24 07:36:28 <LetoThe2nd> must be some collective psychological issue.
Oct 24 07:36:54 <mranostay> LetoThe2nd: we love violence but show any nudity and oh boy :)
Oct 24 07:37:29 * mranostay shoots a handgun in the air to make up for this talk :)
Oct 24 07:37:45 <LetoThe2nd> indeed.
Oct 24 07:42:11 <mranostay> LetoThe2nd: so you are going to E-ELC correct?
Oct 24 07:49:19 <tasslehoff> koen: is
Oct 24 07:49:27 <tasslehoff> angstrom-v2012.12-yocto1.3 the branch to follow now?
Oct 24 07:50:29 <av500> godmorgon
Oct 24 07:51:36 * mranostay stabs AT&T
Oct 24 07:56:02 <LetoThe2nd> mranostay: yes i am
Oct 24 07:56:31 <woglinde> hi av500
Oct 24 07:57:53 <mranostay> LetoThe2nd: trolling my talk? :P
Oct 24 07:58:09 <LetoThe2nd> mranostay: we'll see.
Oct 24 07:58:32 <mranostay> *gulp*
Oct 24 07:59:03 * LetoThe2nd spreads fear and awe.
Oct 24 07:59:06 <Russ> yay, finally finished part of the wiring project http://www.flickr.com/photos/russdill/8118450801/in/photostream
Oct 24 08:00:07 <mranostay> Russ: home?
Oct 24 08:00:47 <Russ> home
Oct 24 08:00:56 <mranostay> nice
Oct 24 08:04:49 <mranostay> LetoThe2nd: all you damn trolls are going to be in the front row i know it! :P
Oct 24 08:05:19 * LetoThe2nd slithers off to checks mranostay's presentation topic to prepare some trolling :)
Oct 24 08:06:55 <LetoThe2nd> strange, linuxfoundation.org looks like there is only one track at elce?
Oct 24 08:07:15 <mranostay> one track?
Oct 24 08:07:36 <LetoThe2nd> their web page is considerably misleading, IMHO
Oct 24 08:07:51 <mranostay> there is multiple talks at the same time
Oct 24 08:08:26 <LetoThe2nd> ah no, its bubbles below each other that are simultaneously. what idiot created that visualization?!?
Oct 24 08:09:40 <mranostay> heh
Oct 24 08:10:11 <mranostay> btw i don't believe in god but thank that non-existant being for the first slot after the keynotes :)
Oct 24 08:10:26 <LetoThe2nd> hrrhrrrrhrrrrrrrr
Oct 24 08:27:55 <av500> Russ: runnign a neighbourhood phone exchange?
Oct 24 08:28:26 <mranostay> people have land lines still?
Oct 24 08:31:05 * av500 loves looking at american wiring pictures
Oct 24 08:31:28 <av500> apply a sepia filter and you have instant steampunk
Oct 24 08:35:00 <Russ> av500, its all mine, mine!
Oct 24 08:35:11 <Russ> mranostay, the land line is only for backup 911 service
Oct 24 08:35:11 <mranostay> o_O
Oct 24 08:35:30 <mranostay> for AZ?
Oct 24 08:35:40 <av500> Russ: that 110 block is that phone or network?
Oct 24 08:35:46 <Russ> CA
Oct 24 08:35:49 <Russ> phone
Oct 24 08:35:58 <mranostay> you are in CA now?
Oct 24 08:36:00 <Russ> CA has soft tone service
Oct 24 08:36:01 <Russ> yes
Oct 24 08:36:07 <mranostay> since when?
Oct 24 08:36:12 <Russ> august
Oct 24 08:36:23 <mranostay> ah where?
Oct 24 08:36:30 <Russ> chino hills (la area)
Oct 24 08:37:12 <av500> Russ: wiring a call center?
Oct 24 08:37:30 <Russ> the stuff on the left is ethernet, not phone
Oct 24 08:38:02 <av500> yeah, got that
Oct 24 08:38:22 <Russ> and heck, if you are getting a block with 100 pairs, you find a way to use 100 pairs
Oct 24 08:38:54 <av500> I keep plugging stuff into my 24port switch just to get all the lights to blink :)
Oct 24 08:40:33 <mranostay> av500: are you on crack? :)
Oct 24 08:41:23 <av500> have some?
Oct 24 08:44:27 <mranostay> av500: just smoke around my apartment
Oct 24 08:44:55 * mranostay really wonders if he'll have to explain these chats in a job interview someday :P
Oct 24 08:45:41 <Russ> http://www.youtube.com/watch?v=u1l80VONLh8 this is how you know if you really are on crack
Oct 24 08:45:45 <Russ> you made this video
Oct 24 08:48:09 <mranostay> wtf did i just watch?
Oct 24 08:48:28 <Russ> I really have no idea
Oct 24 08:48:46 <mranostay> you posted it :)
Oct 24 08:49:07 <Russ> doesn't mean I comprehend it
Oct 24 08:49:51 <mranostay> av500: pass the crack pipe
Oct 24 08:50:19 * av500 makes some solder fumes
Oct 24 08:50:33 * av500 has a large stock of non-ROHS solder
Oct 24 08:50:37 <mranostay> nerd crack
Oct 24 08:50:48 <mranostay> bah i need the lead stuff
Oct 24 08:51:06 <av500> thats what I meant
Oct 24 08:51:16 <av500> pre-ROHS stuff
Oct 24 08:51:43 <mranostay> yeah i love PB!
Oct 24 08:54:58 <Bolkar> hello everyone, in bb xm how can i access uart2? in dmesg | grep tty it says omap_uart.2 :ttyO2 at ...... is a OMAP UART2. But when i try to send something via ttyO2 it shows up in UART1 . I'm really confused. Any help?
Oct 24 10:28:20 * dm8tbr has a stash of leaded solder :]
Oct 24 11:14:00 <jacekowski> try ttyO3
Oct 24 11:16:10 <mru> someone using fortran numbering?
Oct 24 12:15:12 <Crofton|work> mru, on a dual A9, do you need to enable cycle counter access on both cpu's?
Oct 24 12:15:47 <mru> no
Oct 24 12:15:56 <mru> but each cpu has its own counter
Oct 24 12:16:04 <Crofton> hmm, I'll need to slap the intern around then
Oct 24 12:16:19 <Crofton> yes, I wonder if that is what he was thinking
Oct 24 12:16:35 <Crofton> I have a remote control intern sort off
Oct 24 12:21:46 <mdp> mru, yes, OMAP(tm)s have fortran numbering
Oct 24 12:51:09 <bradfa> mdp, if you haven't tried my v3 uart u-boot patches yet, don't waste your time
Oct 24 12:51:26 <bradfa> needs some fix'in
Oct 24 12:52:03 <koen> are you fixin' to fixing it?
Oct 24 12:52:19 <Crofton|work> koen, you are a slave driver
Oct 24 12:53:48 <koen> just practicing texas colloquialisms
Oct 24 12:53:59 <bradfa> koen, possibly...
Oct 24 12:57:39 <bradfa> well, I could also just be doing something stupid... maybe fixing that first would be a good idea...
Oct 24 13:02:03 * koen pokes jkridner 
Oct 24 13:03:51 * wmat pictures jkridner giggling
Oct 24 13:08:09 <jkridner> :)
Oct 24 13:09:58 <bradfa> mdp, ok, so ignore me saying my patches don't work.  What doesn't work is my ability to count.  If you hook up a uart to the wrong pins it doesn't work... stupid me, needs more coffee...
Oct 24 13:10:16 <bradfa> patches work same as v2 just are easier to read the board file now
Oct 24 13:14:24 <keesj> Did hell just froze over  http://www.raspberrypi.org/archives/2221 first ARM-based multimedia SoC with fully-functional, vendor-provided (as opposed to partial, reverse engineered) fully open-source drivers
Oct 24 13:14:51 <koen> keesj: it's a shim, the juicy bits are still closed
Oct 24 13:15:03 <koen> keesj: but a nice improvement nonetheless
Oct 24 13:16:14 <mdp> bradfa, ok..I've also discovered that txd/rxd wired backwards also causes a failure...crazy
Oct 24 13:16:49 <bradfa> mdp, yah, why can't uarts be like USB? It's impossible to insert those  in backwards...
Oct 24 13:17:00 <av500> bradfa: not true
Oct 24 13:17:02 <bradfa> on average I can plug in a usb on the 3rd try
Oct 24 13:17:17 <av500> usb micro-AB is awesome
Oct 24 13:17:24 <av500> you can plug in the right way easily
Oct 24 13:17:32 <av500> and the wrong way with just a bit more force
Oct 24 13:17:56 <bradfa> mdp, if you have time to test again on your evm, please let me know, shouldn't be any different than v2 patches were as the generated autoconf.mk file is the same but lacking one useless CONFIG
Oct 24 13:18:05 <bradfa> I will send v3 patches to list later today
Oct 24 13:18:05 <mdp> bradfa, let's not try to make usb feel like it does anything right
Oct 24 13:18:10 <bradfa> mdp, good idea!
Oct 24 13:21:29 <av500> koen: quick, think of anything to open source today to counteract that other sutff!!!!!
Oct 24 13:21:32 <av500> anything
Oct 24 13:21:52 <av500> like the DSS FIR filter calcutor....
Oct 24 13:43:16 <koen> jkridner: have a look at the README: https://github.com/beagleboard/kernel/tree/3.7
Oct 24 13:43:26 <jkridner> k
Oct 24 13:43:34 <av500> it'S tl;dr
Oct 24 13:46:08 <mdp> fghjf;dr
Oct 24 13:53:34 <koen> armin76: are you attending ELC-E?
Oct 24 14:10:49 <alan_o> It's ELC-E slide-making day. Staring at a blank page.......
Oct 24 14:11:27 <av500> less is more
Oct 24 14:11:59 <av500> put a corporate logo and a page number and you are done
Oct 24 14:12:45 <alan_o> and a penguin.
Oct 24 14:13:45 <av500> yep
Oct 24 14:14:43 <LetoThe2nd> and if you have nothing to say in the end either babes (for a marketing audience) or fancy images of uber-next-gen hardware (for nerds)
Oct 24 14:15:17 <LetoThe2nd> or babes holding images of uber-next-gen-hardware for mixed audiences or if you just want to be bulletproof. ;)
Oct 24 14:15:38 <panto> babes and nerds don't mix well
Oct 24 14:15:52 <av500> nonsense
Oct 24 14:16:03 <av500> you can always use cages
Oct 24 14:16:09 <av500> ...for the nerds...
Oct 24 14:16:30 <alan_o> So here's the challenge: to get the words bit-bang and "exact steps" into my presentation.
Oct 24 14:16:35 <panto> babes get hand shaped smudges on their backsides & nerds get hand shaped redness on their faces
Oct 24 14:16:56 <LetoThe2nd> panto: well, maybe on the other side of the pond.
Oct 24 14:17:27 <panto> it's pond side irrelevant
Oct 24 14:17:36 <alan_o> yeah, I think this is why LF has an anti-sexual-harassment policy.....
Oct 24 14:19:40 <av500> fingers off Pond!
Oct 24 14:20:38 * LetoThe2nd thinks av500 fingers off bond.
Oct 24 14:25:21 <mru> speaking of presentations I need to think of something for next stateside ELC
Oct 24 14:26:08 <mru> how about "Using retro-modulation to increase throughput in the cyberspectrum"?
Oct 24 14:28:36 * dm8tbr thinks mru overmodulated on the psychoactive-spectrum
Oct 24 14:29:24 <mru> you think I need to double-check that latest batch of coffee?
Oct 24 14:29:45 <mru> I doubt that's the cause though
Oct 24 14:29:56 <mru> I'm still only on the 3rd cup today
Oct 24 14:30:01 <av500> there is also that bat-shit coffee
Oct 24 14:30:10 <av500> or was it cat-shit?
Oct 24 14:30:23 <av500> cat might have gone off
Oct 24 14:30:26 <jkridner> koen: do I need to load any kernel modules or just change the uenv.txt?
Oct 24 14:30:42 <koen> jkridner: for what?
Oct 24 14:31:12 <jkridner> for the link to a kernel you sent me.
Oct 24 14:31:20 <dm8tbr> .oO(LOAD ALL THE MODULES!!!)
Oct 24 14:31:31 <koen> jkridner: no need for kernel modules, but important stuff is builtin
Oct 24 14:31:41 * dm8tbr seems to have overdosed on coffee too
Oct 24 14:31:47 <koen> jkridner: and no need to change uEnv, since this has the dtb appended
Oct 24 14:36:49 <mdp> die append dtb die
Oct 24 14:38:09 <koen> mdp: it's the special build for jkridner so he only needs to replace uImage :)
Oct 24 14:38:20 <mdp> exact steps
Oct 24 14:39:43 <av500> mdp: why die?
Oct 24 14:39:46 <av500> its the only sabe thing to do
Oct 24 14:39:49 <av500> sane
Oct 24 14:39:56 <av500> at least from my POV
Oct 24 14:41:19 <jkridner> performing reboot now
Oct 24 14:41:36 <mdp> turns a multi platform image into a single platform image
Oct 24 14:42:00 <alan_o> I like the dtb appended
Oct 24 14:42:24 <alan_o> The idea of a multi-platform uImage is a bit silly for many embedded cases.
Oct 24 14:42:35 <mdp> but not all
Oct 24 14:43:13 <alan_o> no, not all, but it's an example of where the "sometimes" case drives the most-of-the-time case to be more difficult.
Oct 24 14:44:22 <mdp> we went through this on powerpc too
Oct 24 14:45:11 <alan_o> What's the feeling over on that side now?
Oct 24 14:45:12 <koen> alan_o: in DT land I need a seperate DT for xM and classic beagle
Oct 24 14:45:21 <av500> mdp: from my POV, I cannot rely to update a kernel onto a device where I cannot sure what DT will be passed
Oct 24 14:45:25 <mdp> alan_o, it got  much easier to do a board port
Oct 24 14:45:30 <koen> alan_o: so with an appended DT I loose half my platform support I have now
Oct 24 14:45:45 <mdp> alan_o, but DT still doesn't work properly for multicore systems
Oct 24 14:46:00 <jkridner> koen: Linux beaglebone 3.7.0-rc2 #277 SMP Wed Oct 24 12:09:39 CEST 2012 armv7l GNU/Linux
Oct 24 14:46:05 <av500> koen: so apped 2 DTs
Oct 24 14:46:12 <av500> and select one via the machine ID
Oct 24 14:46:21 <mru> now we're at the unpleastant stage where half of drivers don't work w/o dt and the other half don't work with it
Oct 24 14:46:26 <alan_o> av500: does it work that way?
Oct 24 14:46:28 <koen> av500: there is no machine ID anymore
Oct 24 14:46:33 <alan_o> yeah, that
Oct 24 14:46:33 <mdp> av500, machine ID going away
Oct 24 14:46:38 <av500> guys
Oct 24 14:46:59 <av500> then call it DT id
Oct 24 14:47:01 <koen> mru: and half of them have pinctrl support and the other half doesn't
Oct 24 14:47:28 <mdp> mru, I found that retaining platform data was too ugly for the soon to be upstreamed st7735fb and made it a DT-only driver.
Oct 24 14:47:36 <alan_o> So we had a multi-platform solution before (board file and machine ID) and now we have a kernel image and this config file that you have to haul around with it.
Oct 24 14:47:40 <av500> from our experience, there was never a SW update that touched the kernel that did not have changed in board files
Oct 24 14:47:47 <av500> thus, the same changes would be in DT Files
Oct 24 14:47:52 <mdp> mru, I can see why others struggle to deal with mixed pdata/DT drivers, it sucks
Oct 24 14:47:59 <av500> so, either I update bootloader at each update
Oct 24 14:48:04 <av500> or append the DT(s)
Oct 24 14:48:08 <av500> same difference
Oct 24 14:48:18 <koen> av500: the non appended dt can be next to the kernel
Oct 24 14:48:19 <av500> or I make a 3 way split: boot|DT|kernel
Oct 24 14:48:27 <koen> av500: I load uImage and bone.dtb from /boot in ext4
Oct 24 14:48:28 <av500> and update DT|kernel
Oct 24 14:48:34 <av500> same thing
Oct 24 14:48:40 <av500> kernel is married to DT
Oct 24 14:48:58 <av500> appended or same folder is the same
Oct 24 14:49:09 <av500> it is still not write DT once and forget
Oct 24 14:49:15 <alan_o> koen: it's more complicated if you boot from nand. Have to have another partition, or manage address offsets by hand.
Oct 24 14:49:22 <av500> you evolve kernel and DT in locksteop
Oct 24 14:49:31 <av500> alan_o: that is all doable
Oct 24 14:49:34 <av500> not an issue
Oct 24 14:49:35 <mdp> av500, this is true
Oct 24 14:49:50 <av500> so, board files are DTs now, but they go with the kernel
Oct 24 14:49:52 <alan_o> av500: sure it's doable. It's just more complicated.
Oct 24 14:50:09 <alan_o> av500: more (exact) steps
Oct 24 14:50:16 <av500> the other option is to treat DT like ACPI/BIOS
Oct 24 14:50:27 <av500> write it once, and patch it up often
Oct 24 14:50:46 <av500> or hey, embed a good one :)
Oct 24 14:50:56 <alan_o> yeah, don't have bugs.. solved
Oct 24 14:50:57 <panto> it is doable to have a transition mechanism, and move pdata drivers to DT step by step
Oct 24 14:50:59 <av500> back to square one
Oct 24 14:51:07 <av500> alan_o: or that
Oct 24 14:51:08 <mdp> smart bootloaders do have the provision to patch it (u-boot)
Oct 24 14:51:10 <panto> what was too bad, was the push to DT before having such a thing in place
Oct 24 14:51:20 <mdp> av500, and that's used on powerpc quite liberally
Oct 24 14:51:30 <av500> mdp: patch as in?
Oct 24 14:51:38 <mdp> runtime modifying the dtb
Oct 24 14:51:44 <av500> not the same thing
Oct 24 14:51:58 <av500> with "patch" I mean: a kernel feature was added and needs a DT change
Oct 24 14:52:08 <av500> or "DT was bad there, it needs fix"
Oct 24 14:52:09 <mdp> mmmm
Oct 24 14:52:19 <mdp> well, the theory is that DT is kernel independent ;)
Oct 24 14:52:23 <mdp> ;) ;) ;)
Oct 24 14:52:29 <av500> like board files were
Oct 24 14:52:31 <av500> NOT
Oct 24 14:52:34 <mdp> can I emphasize that enough? ;)
Oct 24 14:52:39 <av500> and BIOS/ACPI was
Oct 24 14:52:40 <av500> NOT
Oct 24 14:53:00 <alan_o> av500: no no, DT in theory is supposed to work with other OS's, not just Linux
Oct 24 14:53:11 <av500> same as BIOS
Oct 24 14:53:16 <av500> not the issue here
Oct 24 14:53:19 <mdp> there *is* a lot greater care being taken to not have many kernel-isms in the DT bindings
Oct 24 14:53:19 <koen> jkridner: does it give you a warm fuzzy feeling to run 3.7rc2 on your bone?
Oct 24 14:53:36 <mdp> av500, for one, that fact that you can't have any board file callbacks changes a lot
Oct 24 14:53:48 <panto> mdp, right, you move to a data only model
Oct 24 14:53:52 <panto> no callbacks
Oct 24 14:53:59 <av500> so where is the logic now?
Oct 24 14:54:03 <av500> still in the kernel?
Oct 24 14:54:09 <mdp> I've got an open disagreement about this fact right now with the developer handling hwmod resets
Oct 24 14:54:21 <alan_o> av500: There is no logic.
Oct 24 14:54:23 <panto> DT can describe the interface and configuration of an arbitrary module better
Oct 24 14:54:25 <mdp> av500, that's the trick...everything now has to be abstracted somewhere in drivers/*
Oct 24 14:54:26 <av500> if I used to have an if() in a board file, where is that if() now?
Oct 24 14:54:39 <jkridner> koen: yes. yes, it does.
Oct 24 14:54:41 <panto> av500, it's in the DT
Oct 24 14:54:42 <mdp> av500, so take a look at the power sequencing framework that's in play now
Oct 24 14:54:46 <av500> so DT has logic?
Oct 24 14:54:51 <mdp> that stuff used to happen in the board file
Oct 24 14:54:53 <panto> it has statements
Oct 24 14:55:00 <mdp> no logic
Oct 24 14:55:07 <alan_o> no conditionals
Oct 24 14:55:10 <alan_o> no loops
Oct 24 14:55:12 <alan_o> no #defines
Oct 24 14:55:15 <av500> see
Oct 24 14:55:17 <jkridner> looks like I have some fun Bonescript issues to handle on it...
Oct 24 14:55:28 <mdp> alan_o, the latter is coming...see the dtc list
Oct 24 14:55:34 <jkridner> the I2C EEPROM reading, for example, isn't working.
Oct 24 14:55:52 <alan_o> mdp: ah, ok. I know there has been debate about it. Some have been opposed.
Oct 24 14:56:00 <mdp> av500, so anything that is "logic" that's in board files now has to be abstracted into a framework that lives drivers/*
Oct 24 14:56:03 <panto> av500, git://github.com/pantoniou/linux-bbxm.git branch capebus-v1
Oct 24 14:56:24 <av500> mdp: and into your clever uboot that rewrites DT files
Oct 24 14:56:25 <jkridner> hmm... GPIO fail.
Oct 24 14:56:25 <mdp> that's led me to tentatively propose a "reset framework" cause I have a driver that needs to assert/deassert reset
Oct 24 14:56:29 <panto> see how it is possible to handle versions in a purely DT manner
Oct 24 14:56:34 <koen> jkridner: if you have a cape attached, have a look at /sys/bus/capebus
Oct 24 14:56:57 <mdp> av500, yes, go back and see why we've all been laughing about linus' trained bootloader monkeys statement from g+
Oct 24 14:57:09 <mdp> it's a collision of two mindsets
Oct 24 14:57:30 <mdp> most things are justified by pushing the ugliness into the bootloader
Oct 24 14:57:34 <av500> mdp: because in this case you are splitting knowledge that used to reside in one place into 2 places
Oct 24 14:57:43 <av500> and you have to update both
Oct 24 14:57:43 <mdp> right
Oct 24 14:57:46 <alan_o> mdp: av500: YES
Oct 24 14:57:47 <alan_o> that
Oct 24 14:57:51 <av500> so you cannot just update a kernel
Oct 24 14:57:58 <av500> you need to update the boot loader too
Oct 24 14:58:01 <av500> great
Oct 24 14:58:03 <panto> av500, no
Oct 24 14:58:06 <mdp> av500, it depends
Oct 24 14:58:10 <av500> :)
Oct 24 14:58:22 <mdp> av500, if you abstract properly then you should have little dependency on the bootloader
Oct 24 14:58:22 <av500> or hey, lets split uboot into a boot part and a dt writer part
Oct 24 14:58:43 <alan_o> So maybe koen can clarify, but there's plan at some point to write an eeprom from userspace on the bone with configuration settings, then read that eeprom from the bootloader, then use that data to create and compile a DT to hand to the kernel.
Oct 24 14:58:44 <mdp> ughle
Oct 24 14:59:00 <panto> alan_o, no
Oct 24 14:59:04 <av500> alan_o: an eprom? are you nuts? have you seen the BOM cost?
Oct 24 14:59:11 <av500> all you can have is an GPIO
Oct 24 14:59:15 <koen> jkridner: http://pastebin.com/6fqGd6VU
Oct 24 14:59:19 <panto> you don't have to do anything this ugly
Oct 24 14:59:20 <mdp> av500, this is the TI EVM/community-board-centric idea
Oct 24 14:59:37 <av500> some people output real products
Oct 24 14:59:57 <av500> and what you dont want with 100k units out in the field is to depend on some DT somewhere
Oct 24 15:00:07 <mdp> av500, in an internal forum to our group I made it quite clear that you can't expect real customers to include an eeprom...I think everybody got the message
Oct 24 15:00:07 <panto> their life can be better with it
Oct 24 15:00:14 <koen> alan_o: we made the capes a bus in linux, so no need to bootloader smarts anymore
Oct 24 15:00:28 <av500> so you will make sure that all 100k units get a kernel and a matching DT
Oct 24 15:00:39 <av500> thus you update BOTH together allways
Oct 24 15:00:40 <alan_o> koen: ah, I'm just behind.
Oct 24 15:00:41 <mdp> av500, whereas that is fine if TI wants to spend $$$ to have a single image u-boot experience
Oct 24 15:00:51 <av500> fine
Oct 24 15:00:52 <av500> have that
Oct 24 15:00:59 <mdp> I've come to accept that
Oct 24 15:01:07 <panto> av500, even your GPIO can be made to work
Oct 24 15:01:12 <av500> i know
Oct 24 15:01:16 <koen> alan_o: it's quite new :)
Oct 24 15:01:17 <panto> there's nothing that says you have to have an EEPROM
Oct 24 15:01:25 <panto> an eeprom is just more well defined
Oct 24 15:01:30 <av500> atm we use a NAND section
Oct 24 15:01:42 <av500> :)
Oct 24 15:01:43 <panto> please check out the tree I've posted
Oct 24 15:01:52 <mdp> panto, just don't mention that damn eeprom...it's an implementation detail
Oct 24 15:02:03 <panto> I'm sure you'll find that it's very easy to modify the method for anything you come up with
Oct 24 15:02:08 <av500> panto: what should I look at?
Oct 24 15:02:22 <mdp> and good grief, it's not even a new thing...we had this crap on our VME boards at moto
Oct 24 15:02:32 <panto> the link to the tree I've posted: git://github.com/pantoniou/linux-bbxm.git branch capebus-v1
Oct 24 15:02:37 <av500> yes
Oct 24 15:02:38 <av500> I see that
Oct 24 15:03:02 <panto> there's absolutely minimal changes to make it work for your case
Oct 24 15:03:30 <panto> don't think we haven't been in your shoes before
Oct 24 15:03:37 <panto> we do understand how things work in the field
Oct 24 15:03:43 <mdp> panto, I've come to understand that it generically solves the problem of resource mgmt on an arbitrary expansion connector/bus
Oct 24 15:04:06 <panto> yes, in a nutshell
Oct 24 15:04:54 <mdp> panto, I miss just having vme and pci as the expansion bus. ;)
Oct 24 15:04:55 <panto> there's no dependency on having an eeprom, or something mandated
Oct 24 15:05:03 <panto> mdp, those days are long gone :)
Oct 24 15:05:04 * mru awaits the day they allow forth code in a DT
Oct 24 15:05:11 <panto> (although I liked VME better)
Oct 24 15:05:13 <mdp> panto, it's easy to get wrapped around the name of it
Oct 24 15:05:22 <mdp> panto, we are *aligned* on VME
Oct 24 15:05:26 <panto> foobus!
Oct 24 15:05:34 <mru> doofus
Oct 24 15:06:05 <mdp> I vote for doofus
Oct 24 15:06:09 <panto> that's both a bus name, and the developer mental capacity statement!
Oct 24 15:06:14 <mdp> alternative: dumass
Oct 24 15:06:34 <mdp> it's clearly a dumb-ass bus
Oct 24 15:06:39 <mru> panto: I thought he was talking about the presidential election
Oct 24 15:06:59 <panto> how can you tell, which is the doofus and which is the dumb-ass?
Oct 24 15:07:09 <mru> mdp: wouldn't that be a dumbus?
Oct 24 15:07:29 <mdp> we have a winner
Oct 24 15:07:35 <mdp> *allwinner
Oct 24 15:08:04 <panto> a10
Oct 24 15:08:38 <mdp> av500, one thing that is a serious pain point for am33xx right now is the fact that we lack these abstractions for all the things people used to do in board files for their custom boards
Oct 24 15:09:10 <mdp> av500, I dread the day we ship the supported SDK on the DT-only 3.8+ kernel :(
Oct 24 15:09:10 <mru> that's where the forth interpreter comes in
Oct 24 15:09:15 <mdp> lol
Oct 24 15:09:27 <mdp> "Can Forth help here?"
Oct 24 15:09:40 <mru> use the forth
Oct 24 15:09:45 <panto> "here help forth can"
Oct 24 15:10:06 <mdp> your whiskey bottles empty yet? ;)
Oct 24 15:10:55 <mdp> av500, there will be mass confusion and failure to launch with it, IMHO
Oct 24 15:11:08 <panto> mdp, we can't help abstracting things that are too specific to be abstracted... but we can put a mechanism to do your own (very weird) thing if need be
Oct 24 15:11:20 <alan_o> forth interpreter in kernel..... and that's somehow better than loading a compiled module to do the board stuff (of course it would have to be a new kind, that the bootloader could pass in)
Oct 24 15:11:53 <mdp> panto, we do need a standard place to put hacks
Oct 24 15:11:57 <alan_o> I mean, in my mind that's what it keeps coming down to. There's stuff that will need to be done that's not easily described by just data
Oct 24 15:12:01 <alan_o> yes, those hacks.
Oct 24 15:12:22 <mdp> alan_o, yes, this has been an anticipated issue for a long time
Oct 24 15:12:34 <mdp> board files contain more than data
Oct 24 15:12:36 <alan_o> mdp: oh yeah. no doubt about it.
Oct 24 15:12:42 <alan_o> absolutely.
Oct 24 15:12:56 <av500> yes
Oct 24 15:13:01 <av500> that was my point
Oct 24 15:13:02 <mru> alan_o: code is data
Oct 24 15:13:08 <mdp> and evms represent about .0000001% of use cases
Oct 24 15:13:37 <mdp> one thing I learned is that it only takes 1 custom board to mess up your perfectly design code base
Oct 24 15:13:38 <alan_o> mdp: maybe, but lots of systems need hacks.
Oct 24 15:13:49 <mdp> I had that happen numerous times on ppc4xx
Oct 24 15:14:13 <mdp> alan_o, custom trees will continue to hack stuff in the drivers
Oct 24 15:14:38 <mdp> it's not like people abstracted stuff properly back to use function pointers in pdata for board file stuff...except upstream
Oct 24 15:15:28 <mdp> and after a two year period where people yell and scream that it's ugly, somebody will manage to get an abstraction upstream
Oct 24 15:15:47 <panto> IMO if the path of least resistance is to use DT, that's what people will use
Oct 24 15:16:01 <mdp> panto, do remember the time when phys_addr_t was evil? ;)
Oct 24 15:16:06 <panto> the board file hacks tend to be hard to maintain if they are too complex :)
Oct 24 15:16:09 <panto> hehe
Oct 24 15:16:25 <mdp> panto, david miller berated me publicly for trying to introduce that.
Oct 24 15:16:45 <panto> you were evil...
Oct 24 15:17:05 <mdp> it's all timing in the cycle of acceptability ;)
Oct 24 15:18:00 <alan_o> For the record, I don't disagree that we need to do DT. It's been declared the future direction in the kernel, and we must go that way. But I can still lament :)
Oct 24 15:18:45 <mdp> alan_o, yeah, I've been there. then you go back to work
Oct 24 15:19:21 <mdp> I lament having to work in the crappy arch/arm/ world on a daily basis...but that's where we are these days ;)
Oct 24 15:20:48 <panto> mdp, could be worse
Oct 24 15:20:50 <panto> could be x86
Oct 24 15:20:56 <mdp> aieeeee
Oct 24 15:21:09 <panto> so stfu & gbtw :)
Oct 24 15:21:42 <mdp> alan_o, for the record, DT can fix your lamentations. :P
Oct 24 15:31:41 <mranostay> morning gentlemen, friends, and trolls!
Oct 24 15:34:21 <av500> gm
Oct 24 15:34:59 <_troll_> morning mranostay
Oct 24 15:35:05 <av500> panto: since I am not DT expert, where should I look in that kernel?
Oct 24 15:36:03 <mranostay> mdp: or make them worst. all or nothing kinda thing :)
Oct 24 15:37:36 <Crofton|work> the gathering of the trolls is in another week or so
Oct 24 15:37:47 <Crofton|work> hopefully, I can get out of the US OK
Oct 24 15:40:39 <mranostay> Crofton|work: do we have to throw a ring in a volcano?
Oct 24 15:40:55 <Crofton|work> possibly
Oct 24 15:41:06 <av500> that burning ring of fire
Oct 24 15:41:56 <Crofton|work> http://www.roanoke.com/weather/wb/315747
Oct 24 15:43:05 <av500> hmm, reading DTs makes my brain hurt
Oct 24 15:44:04 <prpplague> hehe
Oct 24 15:44:21 <av500> 0xa0 0x08	/* lcd_data0.lcd_data0, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA */
Oct 24 15:44:30 <av500> but I ranted at that before
Oct 24 15:46:17 <av500> panto: you there?
Oct 24 15:51:51 <av500> yocto all the things: http://www.shapeways.com/model/561183/
Oct 24 15:54:31 <mranostay> av500: er what is the second hole for?
Oct 24 15:55:12 <av500> mranostay: no idea, stopped looking at the stuff I post
Oct 24 16:06:48 <mranostay> joelagnel!
Oct 24 16:06:56 <mranostay> av500: couldn't that be a problem? :)
Oct 24 16:09:42 <mdp> av500, I did mention that dtc seems poised to get preprocessor support
Oct 24 16:09:50 <mdp> so, dtc can help here
Oct 24 16:14:45 <panto> av500, here
Oct 24 16:16:14 <panto> sorry, was a way for a bit
Oct 24 16:16:38 <av500> np
Oct 24 16:16:45 <av500> looking at the capebus stuffs
Oct 24 16:17:05 <panto> managed to find your way around?
Oct 24 16:17:26 <av500> trying to understand the magic that selects e.g. bone_dvi_cape_dvi_00A0_pins
Oct 24 16:18:26 <panto> av500, ok
Oct 24 16:18:34 <panto> it's all done by pinctrl
Oct 24 16:19:38 <panto> you have the nodes that are devices that get instantiated
Oct 24 16:20:09 <panto> when you match the cape (based on name, and version) you select the device node and create them
Oct 24 16:20:38 <panto> some devices are properly OF-ied
Oct 24 16:20:46 <panto> i.e. gpio-leds for example
Oct 24 16:21:01 <panto> this is the standard linux device driver
Oct 24 16:21:41 <panto> other devices are not yet (da8xx), so an adapter dt device gets created by the bone capebus board controller
Oct 24 16:21:53 <panto> and then used in the cape definition
Oct 24 16:22:38 <panto> the dvi cape can actually be a generic-cape; i.e. it doesn't need any special per-cape driver code
Oct 24 16:22:58 <panto> all you have to do is hook it up to the linux device code and it will work
Oct 24 16:24:17 <panto> the geiger cape OTOH, can't be made to work as a generic cape, so it's an assembly of generic parts & a specific driver connecting those parts together
Oct 24 16:25:57 <panto> av500, I agree that the pinctrl syntax is not the best btw
Oct 24 16:26:29 <panto> but it is what it is ATM
Oct 24 16:27:13 <av500> panto: if I made a cape runtime pluggable
Oct 24 16:27:32 <panto> should work exactly the same
Oct 24 16:27:32 <av500> lets say I plug the product on a dock
Oct 24 16:27:46 <av500> and some pins change function
Oct 24 16:28:14 <panto> this is not a use-case that works right now of-course
Oct 24 16:28:22 <av500> sure
Oct 24 16:28:28 <panto> but the driver core is flexible enough for it to be made to work
Oct 24 16:28:32 <av500> ic
Oct 24 16:28:45 <panto> note this is very alpha stuff ATM
Oct 24 16:28:59 <panto> hint, it could use a review
Oct 24 16:29:12 <panto> what is missing is resource management
Oct 24 16:29:29 <panto> I have a few ideas how to do that
Oct 24 16:29:52 <panto> but I'm in a feature freeze until I get it polished enough to post
Oct 24 16:30:54 <panto> in your case, for your custom board
Oct 24 16:31:03 <panto> you'd make a board controller (similar to the bone)
Oct 24 16:32:43 <panto> your addressing method will be based on a id read via GPIO, or be encoded by the position of the board
Oct 24 16:32:59 <panto> no idea what is it that you use of-course
Oct 24 16:33:18 <panto> but the addressing is part of the board controller
Oct 24 16:35:31 <av500> panto: board controller example in the kernel somewhere?
Oct 24 16:35:37 <panto> yes
Oct 24 16:35:49 <panto> drivers/capebus/board/*bone*
Oct 24 16:36:38 <av500> panto: stupid question, why is TI putting to much effort in these bone capes?
Oct 24 16:36:57 <panto> TI doesn't
Oct 24 16:36:58 <panto> I do
Oct 24 16:37:01 <av500> ah :)
Oct 24 16:37:04 <av500> makes sense
Oct 24 16:37:06 <panto> at least on the s/w side
Oct 24 16:37:13 <panto> cco does on the h/w side
Oct 24 16:37:33 <av500> right
Oct 24 16:37:56 <panto> it is solving problems that TI will have to face before long
Oct 24 16:38:00 <panto> i.e. EVMs
Oct 24 16:38:54 <panto> with the 3.8 killing board files it's something everyone will face too
Oct 24 16:39:15 <mru> farce
Oct 24 16:39:51 <panto> mru, perhaps
Oct 24 16:40:04 <panto> it's the writing on the wall IMO
Oct 24 16:40:18 <mdp> TI puts effort into *some* capes that have customer value
Oct 24 16:40:27 <mdp> or plans too
Oct 24 16:40:55 <panto> TBH TI pays me for the s/w capebus work, it's just not on their radar so much
Oct 24 16:41:00 <panto> not full-time on it anyway
Oct 24 16:41:01 <mdp> e.g. camera cape...since it fills the camera i/f gap on am335x
Oct 24 16:48:44 <av500> http://www.raspberrypi.org/archives/2221#comment-35002
Oct 24 16:49:52 <av500> haha: http://www.raspberrypi.org/archives/2221#comment-35048
Oct 24 16:52:19 <mru> I'd laugh if it wasn't so sad
Oct 24 16:52:53 <prpplague> av500: this is hilarious
Oct 24 16:53:01 <prpplague> the audacity of these people
Oct 24 16:53:34 <mru> it's how it's done these days
Oct 24 16:56:21 <mru> it happens in every market once the majority is too stupid to tell fact from fiction
Oct 24 16:56:34 <mru> it's how companies like apple thrive
Oct 24 16:56:36 <prpplague> mru: undeed
Oct 24 16:56:38 <prpplague> indeed
Oct 24 16:57:07 <panto> mru, correction, at least apple is reasonably competent
Oct 24 16:57:15 <panto> they might be evil, but they're not fools
Oct 24 16:57:24 <mru> _they_ are not fools
Oct 24 16:57:27 <mru> the iTards are
Oct 24 16:57:36 <panto> iTards != apple
Oct 24 16:57:47 <mru> THAT'S MY POINT
Oct 24 16:57:49 <panto> the itards are just followers
Oct 24 16:57:56 <mru> exactly
Oct 24 16:58:04 <panto> ok, we're saying the exact same thing :)
Oct 24 16:58:12 <mru> apple knows how to exploit them
Oct 24 16:58:25 <mru> "this is magical and revolutionary"
Oct 24 16:58:35 <panto> no-one can say that the rpi people are the same level of competence as apple
Oct 24 16:58:37 <mru> only works if the audience is too stupid to see the lies
Oct 24 16:58:44 <mru> thank goodness
Oct 24 16:58:48 <jkridner> koen: my kernel log is overflowing with messages about USB sleep
Oct 24 16:59:06 <panto> jkridner, stick a usb device in the slot
Oct 24 16:59:12 <panto> musb is unreasonably chatty
Oct 24 16:59:39 <jkridner> k. probably want to cut down on the messages if it isn't an error.
Oct 24 17:00:03 <panto> jkridner, right
Oct 24 17:02:18 <mdp> jkridner: talk to the musb owner
Oct 24 17:03:01 <mranostay> mdp: poor sul :)
Oct 24 17:03:03 <mranostay> *soul
Oct 24 17:06:21 <jkridner> anyone know why 'pinctrl' is under /sys/kernel/debug?
Oct 24 17:07:28 <alan_o> jkridner: someone probably thinks it shouldn't be done from userspace, except maybe during board bringup.
Oct 24 17:07:34 <alan_o> That's been my guess anyway
Oct 24 17:07:37 <jkridner> :(
Oct 24 17:08:06 * jkridner needs better relations between hardware world and Linux
Oct 24 17:08:24 <alan_o> I think what mdp was saying earlier sums up a lot of the difficulties we have, that our type of dev boards is a really small market compared to what most embedded Linux boards do.
Oct 24 17:09:00 <av500> yes
Oct 24 17:09:36 <jkridner> I think that more people will try to do "silly hardware I/O" tasks with Linux in the future...
Oct 24 17:09:39 <av500> our HW dept did not want to look at omap4 EVM schematics at all
Oct 24 17:09:41 <jkridner> as it has become so cheap to do so.
Oct 24 17:09:50 <av500> instead they asked for panda schematics
Oct 24 17:10:26 <av500> but - we have experience and know what we do
Oct 24 17:10:56 <alan_o> jkridner: I agree, and that's where there's currently some breakdown in expectations.
Oct 24 17:12:16 <mdp> jkridner, it's semantics...try to deemphasize that the name contains "debug"
Oct 24 17:12:25 <jkridner> yikes, the colors are now in the LED names.
Oct 24 17:12:47 <koen> jkridner: we can easily rename the led names
Oct 24 17:12:49 <jkridner> just no reasonable way to create scalable interfaces as it is.
Oct 24 17:12:53 <koen> jkridner: it's all in the DT :)
Oct 24 17:12:54 <jkridner> k.
Oct 24 17:13:07 <mdp> jkridner, you simply aren't permitted to have control knobs in sysfs so they end up in debugfs
Oct 24 17:13:28 <alan_o> mdp: That's not entirely true, debug requires another config item to be turned on in the kernel, and requires being mounted separately
Oct 24 17:13:31 <koen> jkridner: https://github.com/koenkooi/linux/blob/3.7-for-panto-rebase/arch/arm/boot/dts/am335x-bone-common.dtsi#L198
Oct 24 17:14:00 <alan_o> mdp: (my comment was in response to "it's just semantics" not "aren't permitted...")
Oct 24 17:14:18 <mdp> alan_o, my only point is why these things are in debugfs
Oct 24 17:14:26 <mdp> there's not another agreed upon place
Oct 24 17:14:46 <koen> jkridner: keep a record of the weird stuff you encounter, I think most of it can be easily fixed
Oct 24 17:14:56 <jkridner> k
Oct 24 17:15:29 <alan_o> mdp: what do you mean by control knobs? What's the restriction in policy?
Oct 24 17:15:43 <jkridner> I'm trying to bring the basics of bonescript up, along with rebuilding the 3.7 kernel.
Oct 24 17:16:53 <alan_o> mdp: why would pin control be different from configuring /sys/class/gpio, or adc, for example?
Oct 24 17:17:36 <mdp> they don't consider it information necessary to "administer the system"..which is the sysfs gate
Oct 24 17:17:51 <mdp> you can post a patch moving it to sysfs
Oct 24 17:18:09 <alan_o> I know better than to try that :)
Oct 24 17:18:29 <mdp> nothing changes unless you speak up ;)
Oct 24 17:18:35 <mranostay> o_O
Oct 24 17:18:36 <alan_o> Well, that's true too
Oct 24 17:20:10 <mdp> http://lwn.net/Articles/429321/
Oct 24 17:20:34 <mdp> sysfs also has some ABI guarantees
Oct 24 17:21:06 <mranostay> mdp: not  a fan of ioctls? :)
Oct 24 17:21:33 <mdp> i don't care
Oct 24 17:21:42 * alan_o likes ioctl()
Oct 24 17:22:11 <mdp> mranostay, that means that something in sysfs can't change arbitrarily
Oct 24 17:24:15 <mdp> mranostay, I only get excited about things like the DTS names not matching the TRM
Oct 24 17:24:19 <mdp> that induces rage
Oct 24 17:26:12 <panto> does this rage have a clinical name?
Oct 24 17:26:30 <mdp> I often wonder if any of the people whining about the high latency gpio userspace interface will propose a low latency version.
Oct 24 17:26:44 <mranostay> heh
Oct 24 17:26:52 <mranostay> stop the bit banging!
Oct 24 17:26:55 <alan_o> mdp: they just make mmap() solutions.
Oct 24 17:26:57 <mdp> it used to be that those that needed something would introduce an alternative
Oct 24 17:26:59 <mdp> right ;)
Oct 24 17:27:17 <panto> mdp, that was in the old days where people knew what they were talking about
Oct 24 17:27:32 <alan_o> well what's the right way to make it better. I've thought about this some.... I don't see how making something like ioctl() would make it any faster
Oct 24 17:27:35 <panto> now, they just whine and expect things to be delivered on their platter
Oct 24 17:27:35 <mdp> I thought of this the other day again when I saw somebody has introduced an in-kernel gpio block api
Oct 24 17:27:59 <panto> mdp, yes
Oct 24 17:28:02 <alan_o> if you open a file, and keep the handle open, then read() and write() are just moving a single byte. It's an ASCII byte, but so what. Just one byte
Oct 24 17:28:14 <mdp> alan_o, I was thinking a standardized ring-based interface where the ring is mmapped into userspace
Oct 24 17:28:16 <alan_o> how is that slower than ioctl
Oct 24 17:28:16 <alan_o> ?
Oct 24 17:28:27 <panto> it's interesting, but IMO, if you need to do bitbanging on a high speed, bite the bullet and write a driver
Oct 24 17:29:25 <mranostay> panto: but the advanced pointers!
Oct 24 17:29:34 <panto> they thin the herd
Oct 24 17:29:42 <mdp> I like the iio userspace ring model
Oct 24 17:29:55 <panto> it is reasonable
Oct 24 17:29:59 <panto> and pretty fast
Oct 24 17:30:10 <mdp> it solves a good number of the use cases where people resource to hacks
Oct 24 17:30:17 <mdp> s/resource/resort/
Oct 24 17:30:31 <mdp> but somebody that has a need will have to do it ;)
Oct 24 17:30:47 <panto> yep, but the people whining about gpio latency think it's a great idea to toggle bits for an spi driver from their user-space application
Oct 24 17:30:52 <mranostay> what is wrong with the gpio code we have?
Oct 24 17:31:02 <mranostay> it handle pretty good
Oct 24 17:31:07 <mdp> mranostay, what's wrong with the beer we gots?
Oct 24 17:31:11 <panto> mranostay, it's slower than banging on the register directly
Oct 24 17:31:15 <mranostay> yes! someone got it :)
Oct 24 17:31:17 <mdp> I saw what you did there. ;)
Oct 24 17:32:21 <alan_o> I suppose I'll have to look at iio
Oct 24 17:33:27 <prpplague> koen: you just try to call?
Oct 24 17:35:01 <koen> prpplague: yes
Oct 24 17:35:09 <koen> prpplague: should I try again?
Oct 24 17:36:26 * koen afk for a while
Oct 24 17:42:29 <mdp> alan_o, fwiw, http://lwn.net/Articles/518259/ is the block gpio api stuff...it helps handle a few bitbanging cases better
Oct 24 17:43:33 <alan_o> yeah, that seems like a good idea
Oct 24 17:43:51 <mdp> even the kernel api is woefully inefficient in that case
Oct 24 17:44:24 <av500> pardon my ignorance, but why is there not /dev/gpio api?
Oct 24 17:44:29 <av500> -t
Oct 24 17:44:42 <panto> because it's extremely hard to do it without specific knowledge of the hardware
Oct 24 17:45:02 <av500> much more complex things like v4l2 do that as well
Oct 24 17:45:11 <unsolo> :P
Oct 24 17:45:20 <alan_o> panto: it would be easy to put what's in sysfs into /dev
Oct 24 17:45:30 <panto> av500, timing is more relaxed for v4l2 :)
Oct 24 17:45:32 <mdp> I've wondered how v4l2 has managed to survive as an ioctl api
Oct 24 17:45:46 <mru> mdp: it's a pretty good api actually
Oct 24 17:45:48 <av500> it can read and write too :)
Oct 24 17:45:52 <mru> and mmap
Oct 24 17:45:55 <av500> if you have time :)
Oct 24 17:45:59 <mdp> mru, I have no problems with it at all
Oct 24 17:46:03 <mdp> don't misunderstand me
Oct 24 17:46:15 <mru> you sound like an ioctl api would be a bad thing
Oct 24 17:46:15 <mdp> I'm just surprised it's allowed to exist with those semantics
Oct 24 17:46:28 <mranostay> panto: not a fan of mmap()ing /dev/mem? :)
Oct 24 17:46:35 <mru> I much prefer direct ioctl over going through a stupid library
Oct 24 17:46:41 <mdp> from an upstream perspective, it has a legacy look compared to everything else
Oct 24 17:47:03 <unsolo> mru: yes and no.. depends on the task/interface etc. imho
Oct 24 17:47:08 <panto> mru, agreed on the stupid library thing
Oct 24 17:47:18 <mru> unsolo: the stupid lib will do ioctl in the end
Oct 24 17:47:19 <mdp> but it's always worked great for me in practice for various interfaces I had to support
Oct 24 17:47:21 <av500> lets not mention specific apis :)
Oct 24 17:47:25 <panto> alsa was/is a train wreck on this subject
Oct 24 17:47:31 <av500> too late
Oct 24 17:47:32 <mru> av500: yeah, we'll keep quiet about alsa
Oct 24 17:47:37 <mranostay> heh
Oct 24 17:47:40 <panto> heh
Oct 24 17:47:41 <unsolo> mru: indeed but it may make things easier for you.
Oct 24 17:47:42 <av500> ok, agreed, do not mention alsa
Oct 24 17:47:44 <mdp> can systemd help here?
Oct 24 17:47:49 <av500> +1100010101
Oct 24 17:47:51 <unsolo> notice the "may"
Oct 24 17:47:52 <av500> ~
Oct 24 17:47:53 <mru> unsolo: v4l2 is _much_ easier to use than alsa
Oct 24 17:47:53 <panto> or even pulseaudio
Oct 24 17:47:59 <mru> eeew
Oct 24 17:48:01 <av500> plusaudio
Oct 24 17:48:02 <mranostay> subsystem that shall not be named!
Oct 24 17:48:03 <unsolo> mru: alsa is indeed painful
Oct 24 17:48:15 <alan_o> ugh, why is audio so freaking hard......
Oct 24 17:48:18 <unsolo> i had so much issues with the alsa api i ended up using jack
Oct 24 17:48:21 <mru> alan_o: it's not
Oct 24 17:48:32 <panto> oss is just fine
Oct 24 17:48:35 <mdp> it seemed like a good idea when OSS did such a crappy job of supporting our gravis ultrasounds
Oct 24 17:48:38 <mru> what panto said
Oct 24 17:48:42 <panto> and the model they use is just fine
Oct 24 17:48:43 <alan_o> mru, ok, why is audio _made_ so hard....
Oct 24 17:49:01 <panto> open a device, get an fd, auto mixing in h/w if supported, s/w mix if not
Oct 24 17:49:01 <mru> alan_o: because people(?) like lennart got involved
Oct 24 17:49:05 <unsolo> alan_o: to make sure audio on linux has issues for the next 10+ years (when written )
Oct 24 17:49:21 <funksdev> Does anyone here boot a beaglebone from the latest omap kernel?
Oct 24 17:49:35 <panto> alsa solves problems that no-one cares about anymore
Oct 24 17:49:36 <mdp> panto, the problem was mostly that the oss folks refused to evolve things
Oct 24 17:49:37 * unsolo has yet to boot his beaglebone
Oct 24 17:49:41 <jkridner> joelagnel: do you have an easy way to program the EEPROM on new boards?
Oct 24 17:49:54 <mru> mdp: nothing _needed_ to evolve all that much
Oct 24 17:50:02 <panto> right, and their monetization attempt
Oct 24 17:50:02 <av500> mdp: one could have kept the OSS API
Oct 24 17:50:10 <av500> API Cannot be monetized :)
Oct 24 17:50:11 <unsolo> btw i was wondering if there any omap5 or other cortex-a15 dev boards out there.. im tired of the fan noise from my laptop
Oct 24 17:50:14 <av500> posner said so
Oct 24 17:50:14 <mru> hey, for a long time (perhaps still) it's more reliable to use the oss emulation than "real" alsa
Oct 24 17:50:21 <mdp> mru, nope, it was a maintainership issue mostly IMHO
Oct 24 17:50:29 <av500> unsolo: I have omap5 board, it has a fan
Oct 24 17:50:39 <alan_o> funksdev: https://github.com/beagleboard/kernel/tree/3.7  (that's mainline)
Oct 24 17:50:45 <mru> mdp: so they could have kept a sane interface under a new maintainer, no?
Oct 24 17:50:46 <unsolo> av500: ouch
Oct 24 17:50:52 * panto had a brush in with pulseaudio internals about a year ago
Oct 24 17:50:58 <mru> unsolo: av500 has a fan of omap5
Oct 24 17:51:06 <unsolo> 's
Oct 24 17:51:09 <panto> still got nightmares out of the experience
Oct 24 17:51:18 <av500> mru: is that a "has a" vs "is a" issue?
Oct 24 17:51:19 <mdp> mru, I think so, but technical issues can get blurred when you have a maintainer problem
Oct 24 17:51:25 <mdp> that was a long time ago too
Oct 24 17:51:35 <av500> OSS4 is ready
Oct 24 17:52:04 <mdp> when wavetable cards were all the rage...and alsa provided an alternative that worked
Oct 24 17:52:14 <alan_o> yeah, what mru and mdp said. I've never felt like those questions never got answered in my head
Oct 24 17:52:16 <panto> mdp, right
Oct 24 17:52:28 <mdp> plus it fit the kernel mindset of doing a lot of stuff that was done in the kernel, out in userspace
Oct 24 17:52:48 <funksdev> alan_o: thanks- i'll give it a shot
Oct 24 17:52:53 <unsolo> so since the omap5 isnt really available i was wondering if perhaps a zotac zbox E-1800 1.7 ghz amd thingie with SSD and 8 gigs of ram would do the trick as my next pc..
Oct 24 17:52:53 <mdp> it almost shouldnt' surprising why the momentum went to alsa as it fits the upstream model
Oct 24 17:52:53 <alan_o> yeah, for some reason sound servers were where it was at
Oct 24 17:52:57 <mru> mdp: yes, things like sample rate conversion should definitely be done in userspace
Oct 24 17:53:04 <mru> but the alsa way is just wrong
Oct 24 17:53:22 <av500> I like how arts resampled 48000 to 48000 and failed
Oct 24 17:53:42 <mdp> hehe
Oct 24 17:53:48 <unsolo> haha
Oct 24 17:53:56 <av500> coworker did SDR via soundcard
Oct 24 17:54:03 <mru> it could be done with the kernel taking the samples from various clients and handing them to a usespace daemon for mixing
Oct 24 17:54:22 <mdp> I just had a coworker look at asoc for the first time and go "WTF??!??!?"
Oct 24 17:54:22 <mru> a little mmap and it could even be zero-copy
Oct 24 17:54:27 <mdp> too funny
Oct 24 17:54:40 <alan_o> mru: Why should it come back to userspace, that's what I don't get
Oct 24 17:54:55 <mru> alan_o: that kind of code doesn't need to be in the kernel
Oct 24 17:54:56 <av500> these days with kernel threads, it can be kernel space too
Oct 24 17:55:00 <mru> therefore it should not be in the kernel
Oct 24 17:55:10 <alan_o> but it's stuff that's already in kernel.
Oct 24 17:55:14 <av500> its a process after all
Oct 24 17:55:15 <alan_o> why should it go in and then come back out
Oct 24 17:55:21 <av500> alan_o: 0-copy
Oct 24 17:55:27 <av500> it goes nowhere
Oct 24 17:55:30 <av500> if done right
Oct 24 17:55:35 <alan_o> it's not the copying
Oct 24 17:55:36 * panto throws his vote for doing the mixing in the kernel 
Oct 24 17:55:43 * av500 would not mind
Oct 24 17:55:47 <alan_o> it's the transfer of ownership/execution
Oct 24 17:55:54 <mru> alan_o: it's like running firefox as root
Oct 24 17:55:55 <av500> i just want dam /dev/dsp to by multiopen capable
Oct 24 17:56:05 <alan_o> av500: yes, that
Oct 24 17:56:10 <mdp> av500, no! ;)
Oct 24 17:56:18 <panto> fight!
Oct 24 17:56:43 <mru> the alsa way, adding an ipc backdoor to every app, is just screaming security problem
Oct 24 17:56:52 * unsolo would prefer dma in and out of userspace for audio mixing/processing in a multiopen event wayt
Oct 24 17:56:57 <unsolo> -t
Oct 24 17:57:07 <mru> no need for dma
Oct 24 17:57:17 <mdp> IIRC, the other issue was also the weird relationship with the commercial fork of OSS and the closed nature of various soundcard makers at the time (Creative)
Oct 24 17:57:33 <mdp> again, more non-technical reasons this path was chosen
Oct 24 17:58:54 <unsolo> mru: depends on how many physical cpu cores you would want to do it on no ?
Oct 24 17:59:04 <mru> no
Oct 24 17:59:15 <mru> if you have shared ram it does not matter
Oct 24 17:59:30 <unsolo> hmm
Oct 24 17:59:41 <unsolo> so if 4 processes listen on the same audio device
Oct 24 17:59:49 <mru> 1. client requests buffer from driver
Oct 24 17:59:54 <mru> 2. client writes samples to buffer
Oct 24 18:00:16 <mru> 3. client submits buffer for playback
Oct 24 18:00:26 <mru> 4. kernel passes buffer to mixing daemon
Oct 24 18:00:43 <mru> 5. daemon requests output buffer from driver
Oct 24 18:00:50 <unsolo> why the request submit ..
Oct 24 18:00:51 <mru> 6. daemon mixes all input into output
Oct 24 18:01:06 <mru> 7. daemon submits output buffer to kernel for playback
Oct 24 18:01:13 <mru> 8. actual playback
Oct 24 18:01:28 <unsolo> wouldnt a simple ringbuffer interaction with the kernel be better ?
Oct 24 18:01:41 <mru> details
Oct 24 18:01:51 <unsolo> :)
Oct 24 18:02:13 <mru> buffer ownership has to be tracked one way or another
Oct 24 18:02:23 <unsolo> but yea something like that would be nice.
Oct 24 18:02:39 <mru> the userspace daemon could then do whatever the hell it wants
Oct 24 18:02:51 <mdp> dma-bufs, solved generically
Oct 24 18:02:53 <unsolo> and ofc a nice "mixer" api some event mechanism
Oct 24 18:03:07 <mru> that's just sugar
Oct 24 18:03:15 <unsolo> yea but its all there..
Oct 24 18:03:24 <alan_o> mru: It seems high-latency to go back and forth from kernel space
Oct 24 18:03:32 <unsolo> alan_o: oO
Oct 24 18:03:33 <mru> compared to what?
Oct 24 18:03:46 <mru> alsa does user-user ipc instead
Oct 24 18:03:53 <mru> which involves syscalls too
Oct 24 18:03:54 <alan_o> Compared to making /dev/dsp multi-open and doing mixing in kernel.
Oct 24 18:04:12 <mru> if you care about latency, you don't do mixing
Oct 24 18:04:13 <unsolo> kernel space would simply mix in data from each "source" in a zero copy kinda way
Oct 24 18:04:13 <mru> period
Oct 24 18:04:32 <mru> none of what I described needs any copying
Oct 24 18:04:41 <alan_o> agreed on the copying
Oct 24 18:05:04 <unsolo> mru: the mixer needs to mix together locally before writing out at least.
Oct 24 18:05:19 <unsolo> and since rate conversion is a thing one should perhaps have a small buffer as well
Oct 24 18:05:36 <unsolo> also format conversion
Oct 24 18:05:49 <mru> all of which can be done equally well in userspace
Oct 24 18:05:54 <av500> format conversion is cheap
Oct 24 18:06:02 <av500> it affects only 1 client, not all
Oct 24 18:06:06 <mru> a kernel thread would incur the same latency
Oct 24 18:06:06 <av500> mixing affects all
Oct 24 18:06:23 <mru> format conversion is pure sugar
Oct 24 18:06:41 <mru> you could easily deman each client supply a single format/rate
Oct 24 18:06:46 <mru> *demand
Oct 24 18:06:47 <panto> mru, in the case where multiple streams can be supported by the h/w, the daemon is not that needed
Oct 24 18:06:55 <mru> sure
Oct 24 18:06:59 <mru> so skip it in those cases
Oct 24 18:07:04 <panto> altough, what I'd do is just kill the formats
Oct 24 18:07:13 <unsolo> mru: jackd..
Oct 24 18:07:16 <panto> select a nice high rate (mono) and just use that
Oct 24 18:07:21 <mru> unsolo: what of it?
Oct 24 18:07:26 <av500> panto: that case is gone now, no?
Oct 24 18:07:40 <av500> i mean hw mixing
Oct 24 18:07:49 <unsolo> jackd interface ->kernel
Oct 24 18:07:51 <panto> av500, yes, for now
Oct 24 18:07:55 <av500> forever
Oct 24 18:07:58 <panto> but it's very cheap in silicon nowadays
Oct 24 18:08:10 <panto> the wheel of re-incarnation will turn again
Oct 24 18:08:27 <panto> it's not going to be about performance, it's going to be about power-draw when playing a game
Oct 24 18:08:32 <av500> with all apps going fullscreen, I dont see the need to mix at all :)
Oct 24 18:08:40 <unsolo> haha
Oct 24 18:08:50 <av500> panto: durign a game you have GPU and LCD
Oct 24 18:08:58 <av500> audio is the least of your concerns :)
Oct 24 18:09:05 <panto> oh I don't know
Oct 24 18:09:19 <av500> unless its an audio only game :)
Oct 24 18:09:23 <av500> I do know
Oct 24 18:09:31 <panto> av500, :)
Oct 24 18:09:37 <av500> at least on our HW
Oct 24 18:09:52 <panto> it's all dependent on the kind of game
Oct 24 18:10:08 <panto> perhaps someone will crunch the numbers differently
Oct 24 18:10:08 <av500> its why intel can make a x86 android phone and its not bad, it has to power the same LCD as the ARM one :)=
Oct 24 18:10:16 <panto> heh
Oct 24 18:10:38 <panto> anyway, dinner time
Oct 24 18:10:48 <av500> panto: souvlaki?
Oct 24 18:10:59 <panto> that's very stereotypical
Oct 24 18:11:01 <panto> so no :)
Oct 24 18:11:15 <av500> its also yummy, so yes :)
Oct 24 18:11:40 <unsolo> av500: what is a bad android phone.. mine is 2.5 years old and still running fine..
Oct 24 18:11:52 <av500> sure
Oct 24 18:13:27 <unsolo> so it should be possible to get a android phone running arm that is close to 9 times as fast.. how much faster is the current arm/intel ?
Oct 24 18:14:04 <unsolo> and why design a phone running LCD and not OLED
Oct 24 18:15:00 <mdp> panto, you do know, you were part of the team educating some past customers on the "total bom" power draw and to quit worrying about just the cpu
Oct 24 18:15:16 * unsolo needs to go change tires
Oct 24 18:15:24 <unsolo> its dropping below 0 C here..
Oct 24 18:15:33 <mdp> panto, before android existed at google
Oct 24 18:15:34 <mru> ah, one of those countries
Oct 24 18:15:49 <av500> unsolo: why 9x faster?
Oct 24 18:15:54 <mdp> or unsolo is in the burn-in chamber
Oct 24 18:16:15 <av500> unsolo: and oled vs lcd is a price thing
Oct 24 18:16:17 <av500> and yield
Oct 24 18:16:22 <av500> well, same thing, price
Oct 24 18:16:25 <unsolo> rough more's extrapolation..
Oct 24 18:16:39 <av500> 2x in 18month, no?
Oct 24 18:16:43 <unsolo> av500: the apple lcd thingie is still more expensive..
Oct 24 18:18:17 <av500> ?
Oct 24 18:18:31 <unsolo> av500: so maybe 4x would be correct
Oct 24 18:19:16 <unsolo> still the fact remains what is needed in hw and what is present tend to differ even in mobile phones
Oct 24 18:19:47 <av500> 4x is roughly the case
Oct 24 18:21:14 <jkridner> Tartarus: have you tried configuring SPL for Y-modem?
Oct 24 18:21:16 <unsolo> a quad A9 1,5 is a lot more powerful than my single 1ghz armv7 snapdragon
Oct 24 18:21:21 <Tartarus> Yeah
Oct 24 18:21:25 <jkridner> it seems to be in the config, but I'm not getting any response back.
Oct 24 18:21:27 <Tartarus> Works fine, use it often :)
Oct 24 18:21:31 <jkridner> k
Oct 24 18:21:41 <Tartarus> Did you load the first part via xmodem?
Oct 24 18:21:42 <janne> av500: probably more if there were software which makes use of 4 cores
Oct 24 18:21:45 <unsolo> mru: i continued looking at the MMU stuff today and performance is really bad.. ;(
Oct 24 18:21:49 <av500> janne: indeed
Oct 24 18:21:57 <jkridner> I'm trying 'sx MLO > /dev/ttyUSB0 < /dev/ttyUSB0' and that seems to complete...
Oct 24 18:22:07 <av500> that why the single core atom smokes all the manycory phones on webspider
Oct 24 18:22:12 <jkridner> but, I don't see any output from the serial port after htat.
Oct 24 18:22:21 <mru> unsolo: you must be holding it wrong
Oct 24 18:22:22 <av500> or sunspider
Oct 24 18:22:28 <unsolo> mru: i think so
Oct 24 18:22:43 <unsolo> but im having a few days off it to see if i can figure out how to hold it properly..
Oct 24 18:22:43 <av500> quadcore is just to write "more of something" on the box
Oct 24 18:23:06 <Tartarus> jkridner: OK, first use a real comm program like screen? :)
Oct 24 18:23:08 <Tartarus> I do..
Oct 24 18:23:09 <unsolo> av500: people should write more "distributed" stuff
Oct 24 18:23:19 <av500> people dont do anything
Oct 24 18:23:19 <Tartarus> ## screen commands to load via UART, control-A then...
Oct 24 18:23:19 <Tartarus> :exec !! sx -kb /tmp/u-boot-spl.bin
Oct 24 18:23:19 <Tartarus> :exec !! sx -kb --ymodem /tmp/u-boot.img
Oct 24 18:23:23 <jkridner> does scree...
Oct 24 18:23:25 <jkridner> ah.
Oct 24 18:23:25 <av500> except complaining
Oct 24 18:23:25 <jkridner> k.
Oct 24 18:23:36 <Tartarus> And, ah
Oct 24 18:23:38 <Tartarus> yes, not MLO
Oct 24 18:23:39 <unsolo> av500: :)
Oct 24 18:23:40 <Tartarus> u-boot-spl.bin
Oct 24 18:23:53 <jkridner> oh? I didn't know they were different.
Oct 24 18:24:04 <mranostay> new naming scheme right?
Oct 24 18:24:21 <mru> new scheming
Oct 24 18:25:46 <mdp> Tartarus, s/screen/tmux/
Oct 24 18:26:10 <mdp> Tartarus, j/k..no tty handling in tmux ;)
Oct 24 18:26:45 <Tartarus> No, MLO has a header
Oct 24 18:26:49 <Tartarus> u-boot-spl.bin is the raw file
Oct 24 18:26:55 <Tartarus> ROM requires no header
Oct 24 18:27:29 <jkridner> k.
Oct 24 18:27:35 <jkridner> didn't seem to take
Oct 24 18:27:52 <jkridner> Got the "Give...", but keep seeing "CCCC..."
Oct 24 18:28:49 <Tartarus> If you see no other output then the ROM didn't get the file :)
Oct 24 18:29:29 <unsolo> .S :)
Oct 24 18:29:55 <jkridner> hmmm... i wonder if I'm not understanding the 'exec !!'
Oct 24 18:30:04 <jkridner> and the -kb
Oct 24 18:30:37 <jkridner> I guess -k would be faster.
Oct 24 18:30:48 <jkridner> -b seems superfluous.
Oct 24 18:32:49 <Tartarus> So, that's the format for screen to exec a command and run it as a filter
Oct 24 18:32:56 <panto> back
Oct 24 18:33:01 <Tartarus> I copy/paste those commands from my notes to screen quite often :)
Oct 24 18:33:08 <Tartarus> ^A then the first line, then reset the board
Oct 24 18:33:13 <Tartarus> sends the first file to the ROM
Oct 24 18:33:16 <panto> unsolo, all I can say is that the A15s are going to be a real game-changer
Oct 24 18:33:19 <Tartarus> ^A then the second line sends U-Boot to SPL
Oct 24 18:33:22 <panto> lots of power, lots of problem
Oct 24 18:33:30 <panto> problems
Oct 24 18:33:52 <jkridner> well, when I do it verbatim, I'm getting "NAK on sector"
Oct 24 18:39:04 <jkridner> I think I finally understand http://www.gnu.org/software/screen/manual/html_node/Exec.html#Exec, but it is ugly!
Oct 24 18:39:27 <ds2> why not use kermit? simplier and less cruft
Oct 24 18:41:24 <mranostay> ugly as javascript?
Oct 24 18:41:26 * mranostay ducks
Oct 24 18:41:55 <Tartarus> ds2, to send via xmodem? :)
Oct 24 18:41:59 <Tartarus> ROM groks xmodem only
Oct 24 18:42:07 <ds2> sure
Oct 24 18:42:16 <jkridner> javascript isn't really any uglier than C.  certainly not than C++. The DOM is grotesque.
Oct 24 18:42:20 <ds2> kermit is a terminal software not just protocol
Oct 24 18:42:28 <Tartarus> Ah, right
Oct 24 18:42:30 <ds2> you can call sx to handle xmodem
Oct 24 18:42:35 <Tartarus> Yeah, sure, whichever terminal emulator you like :)
Oct 24 18:42:38 <ds2> actually, for xmodem, why are you using -b?
Oct 24 18:42:42 <Tartarus> minicom has some crap you can configure too
Oct 24 18:42:48 <Tartarus> I just <3 screen since I'm using it for everything else
Oct 24 18:42:55 <Tartarus> haven't been converted to tmux yet, sorry mdp
Oct 24 18:43:47 <Tartarus> ds2, clarity or copy/paste.  I found something that worked and I just copy/paste that when needed so a few more keystrokes doesn't hurt
Oct 24 18:47:32 <jkridner> kermit didn't work either.
Oct 24 18:47:52 <jkridner> at least from the command line, the transfer completes.
Oct 24 18:50:36 <jkridner> is ROM 8N1?
Oct 24 18:55:49 <Tartarus> yup
Oct 24 18:56:23 <Tartarus> You aren't using any funny unreleased hardware, right? :)
Oct 24 18:56:35 <jkridner> I am, actually....
Oct 24 18:56:48 <jkridner> I will try other hardware, I suppose.
Oct 24 18:56:56 <Tartarus> Yeah, do that first
Oct 24 18:57:05 <Tartarus> Then go see what's setup wrong on that funny thing
Oct 24 18:57:07 <Tartarus> :)
Oct 24 19:00:21 <jkridner> interesting...
Oct 24 19:00:52 <jkridner> it seems to have been failing because the transfer was starting without the press of RESET.
Oct 24 19:01:07 <jkridner> I was catching it later in the boot process.
Oct 24 19:01:17 <jkridner> boot succeeded on BeagleBone.
Oct 24 19:05:16 <jkridner> hmm... or maybe something else...
Oct 24 19:05:19 <jkridner> very odd...
Oct 24 19:05:23 <jkridner> same processor...
Oct 24 19:05:36 <jkridner> obvious difference is on-board FTDI vs. external FTDI
Oct 24 19:06:27 <av500> ...In the time it has taken Microsoft to bring Windows on ARM to market, ARM's once overwhelming battery life advantage has been erased....
Oct 24 19:06:34 <av500> http://arstechnica.com/gadgets/2012/10/now-that-its-here-is-there-a-place-for-windows-rt/
Oct 24 19:09:11 <av500> koen: http://meuk.spritesserver.nl/foto/gallery/image/14280/IMG_0853.JPG
Oct 24 19:10:36 <jkridner> hmmm... wrong processor board.
Oct 24 19:10:53 <jkridner> pretty slick.
Oct 24 19:11:19 <av500> yes, rpi gets all the cool stuff
Oct 24 19:11:52 <av500> evne open source drivers
Oct 24 19:12:45 <jkridner> I kinda believed the hype for about 30 seconds.
Oct 24 19:13:56 <ds2> power of imagination ?
Oct 24 19:15:48 <funksdev> For beaglebone mainline- could someone explain the dtbs make option?
Oct 24 19:17:19 <funksdev> I build with it but got make[1]: Nothing to be done for `arch/arm/boot/dtbs' and can't find the am335x-bone.dtb to copy into /boot
Oct 24 19:18:25 <mdp> make am335x-bone.dtb
Oct 24 19:18:45 <mdp> unless you have the patch that adds bone&evm to the list of all dtbs to be made
Oct 24 19:19:21 <mdp> https://patchwork.kernel.org/patch/1394111/
Oct 24 19:19:53 <mdp> that's the old one, sorry
Oct 24 19:20:36 <mdp> https://patchwork.kernel.org/patch/1499401/
Oct 24 19:21:32 <funksdev> thanks
Oct 24 19:21:42 <mdp> np
Oct 24 19:53:16 <alan_o> I liked the target we had in the 3.6 beaglebone kernel which attached it to the uImage :)
Oct 24 19:57:40 <unsolo> panto: id like to get a A15 instead of an embedded x86 but how long would i have to wait to get my hands on one.
Oct 24 19:58:02 * unsolo is replacing his laptop with something fanless (hopefully)
Oct 24 19:58:49 <panto> unsolo, it's going to take a while; I don't have access to one either
Oct 24 19:59:01 <panto> but not very long :)
Oct 24 19:59:54 <mdp> why would it take long to get an A15?
Oct 24 20:00:22 <av500> buy a chromebook
Oct 24 20:00:32 <av500> aint that A15 now?
Oct 24 20:00:34 <mdp> exactly, it's already a commodity
Oct 24 20:01:01 <panto> shiny objects don't count
Oct 24 20:01:12 <panto> boards that I can hack on do
Oct 24 20:01:25 <av500> you can hack on it
Oct 24 20:01:30 <av500> open boot et al
Oct 24 20:01:34 <av500> even put bubnbnutu
Oct 24 20:01:35 <mdp> panto, hack away
Oct 24 20:01:38 * panto has no clue how open the chromebook is
Oct 24 20:01:45 <mdp> brewbuntu
Oct 24 20:01:53 <panto> meh
Oct 24 20:01:57 * panto is a fossil 
Oct 24 20:02:22 <mru> panto: most notebooks will open to at least 160 degrees
Oct 24 20:02:30 <mru> some as far as 180
Oct 24 20:02:40 <mru> which I guess would be considered fully open
Oct 24 20:03:00 <alan_o> Does that mean RPi is fully open?
Oct 24 20:03:05 <alan_o> It doesn't have a hinge to close?
Oct 24 20:03:12 <mru> nor one to open
Oct 24 20:03:12 <av500> it is
Oct 24 20:03:13 <mdp> I can make any laptop open to 180
Oct 24 20:03:15 <av500> they said so
Oct 24 20:03:27 <av500> its fully open source
Oct 24 20:03:28 <panto> if you put enough force they even open to 360
Oct 24 20:03:31 <panto> but only once
Oct 24 20:03:31 * mru hides his laptop from mdp 
Oct 24 20:03:33 <av500> for their definition of fully
Oct 24 20:04:01 <mru> opening an rpi to 360 is probably the best you can do with them
Oct 24 20:04:55 <alan_o> At risk of being flamed, the RPi people make a good point. If we didn't see the GPU firmware, we'd not care. If it was embedded in the GPU, we'd never know.
Oct 24 20:05:32 <mru> that is not a point
Oct 24 20:05:54 <alan_o> no? Isn't the firmware blob the bone of contention?
Oct 24 20:05:58 <alan_o> (a bone)
Oct 24 20:06:14 <mru> I don't care (much) about close firmware as such
Oct 24 20:06:24 <mru> but when it's in charge booting the whole chip, I do
Oct 24 20:06:32 <mru> no blob, no boot
Oct 24 20:06:45 <alan_o> right,but if the blob was embedded in ROM in the chip....
Oct 24 20:07:08 <mru> then I'd get a different chip
Oct 24 20:07:10 <alan_o> and we were told "the chip initializes itself," then what would we say to that?
Oct 24 20:07:19 <alan_o> but many chips have ROM
Oct 24 20:07:28 <mru> there's rom and there's rom
Oct 24 20:07:31 <mru> omap has a rom
Oct 24 20:07:34 <panto> most all recent arm boot from rom anyway
Oct 24 20:07:34 <alan_o> yes
Oct 24 20:07:45 <mru> but you can still configure memory timings and cache setup yourself
Oct 24 20:07:46 <armin76> koen: i have an informal invite... i have to think about it
Oct 24 20:07:49 <mru> in fact, you have to
Oct 24 20:08:21 <mru> and when you do run into things on omap that only the rom can do, it's usually annoying as hell
Oct 24 20:08:40 <mru> since the rom tends to be slightly buggy in various ways
Oct 24 20:08:51 <mru> or at least lack certain features
Oct 24 20:09:16 <mru> and when bcm lose interest and stop updating the firmware, it's as good as hardwired
Oct 24 20:09:20 <mru> *when*
Oct 24 20:12:00 <alan_o> mru: I guess the question is (as always) where is the line between bad ROM and good ROM
Oct 24 20:12:13 <av500> its usually an address line :)
Oct 24 20:12:18 <mru> A20?
Oct 24 20:12:31 <mru> alan_o: I want enough rom to make the device unbrickable but no more
Oct 24 20:12:48 <av500> and unhackable in case of HS :)
Oct 24 20:13:04 <mru> sure, if I'm building a "secure" device
Oct 24 20:13:34 <mru> and I want enough specs that I can boot my OS of choice without relying on binary blobs
Oct 24 20:13:59 <mru> if specific peripherals (gpu, wifi, whatever) need a firmware blob, so be it
Oct 24 20:14:09 * panto mostly hates the ROMs for hogging the FIQ line in the 'secure' domain 
Oct 24 20:14:19 <av500> oh, it does?
Oct 24 20:14:42 <mru> ah, so it's an interrupt line, not an address line
Oct 24 20:14:53 <mru> and clearly that rom has crossed it
Oct 24 20:15:11 <av500> I want irc to have +1 buttons!
Oct 24 20:15:22 * panto +1's av500 
Oct 24 20:15:28 * av500 blushes
Oct 24 20:15:52 <mru> av500: you'll have to bitbang it
Oct 24 20:16:36 * av500 orders "IRC for dummies"
Oct 24 20:16:41 <alan_o> 00110001
Oct 24 20:17:10 <mru> that's a 1, now where's the +?
Oct 24 20:17:12 <alan_o> oh wait, you need a +, dang it.... joke ruined :(
Oct 24 20:20:39 <mru> doesn't matter, I don't remember the ascii code for + anyway
Oct 24 20:21:26 <av500> /ascii should work
Oct 24 20:24:19 <bradfa> mdp, v3 u-boot serial patches sent, little cleaner, if you wanted to update your blog :)
Oct 24 20:38:41 <panto> g'night
Oct 24 20:47:55 <jkridner> Tartarus: if I start 'sx' then power the board up, it works (except that SPL hangs because my EEPROM isn't programmed--which is why I was trying to load it this way in the first place--to have a tool that can program it)
Oct 24 20:48:23 <jkridner> trying to run sx after the ROM bootloader starts sending 'CCC' seems to not work well under 'screen'.
Oct 24 20:49:29 <Tartarus> Gotta catch it in time, yeah
Oct 24 20:49:34 <Tartarus> You've got 6 Cs before the ROM moves on
Oct 24 20:50:11 <jkridner> it is odd that it keeps sending Cs anyway.
Oct 24 20:50:24 <Tartarus> Well, it cycles back around
Oct 24 20:50:33 <ds2> the 33x ROM understands Xmodem internally?
Oct 24 20:50:41 <Tartarus> ds2, yes
Oct 24 20:50:54 <jkridner> do you have a process for writing to the EEPROMs then?
Oct 24 20:51:09 <Tartarus> jkridner: was just about to tell you that you need to whack that in :)
Oct 24 20:51:14 <ds2> wonder if there is a warm/cold reset problem
Oct 24 20:51:24 <ds2> the 35x's behave slightly differently on warm vs cold reset
Oct 24 20:51:54 <Tartarus> When there's no eeprom we just don't know what to do
Oct 24 20:51:59 <Tartarus> So you'll have to make up something
Oct 24 20:51:59 <mdp> bradfa, thx, was dealing with some other stuff today...and the day continues to get worse
Oct 24 20:52:05 <Tartarus> and that's non-mainlineable :)
Oct 24 20:52:22 <jkridner> Tartarus: is there a quick place to hack in am335x_evm.h?
Oct 24 20:53:43 <jkridner> Tartarus: is it all in mux.c?
Oct 24 20:54:01 <Tartarus> board.c too for what ddr we have
Oct 24 20:55:19 <jkridner> what directory is the board.c under?
Oct 24 20:55:40 <jkridner> found it.
Oct 24 20:55:51 <jkridner> /arch/arm/cpu/armv7/am33xx/board.c
Oct 24 20:56:28 <bradfa> mdp, but it's almost beer-thirty, so things will get better :)
Oct 24 20:57:23 <mdp> yes, beer can help here
Oct 24 21:01:53 <jkridner> I'm successfully in u-boot now.
Oct 24 21:02:03 <mranostay> bradfa: it is always beer-thirty
Oct 24 21:02:04 <jkridner> got one more little issue: Incorrect magic number (0xffffffff) in EEPROM
Oct 24 21:03:55 <jkridner> ah... home sweet linux.
Oct 24 21:12:35 <mranostay> jkridner: clearly that EEPROM needs some javascript
Oct 24 21:12:48 * mranostay exits troll mode
Oct 24 21:13:17 <jkridner> ;-)
Oct 24 21:13:35 <jkridner> jk
Oct 24 21:14:13 <mranostay> hehe
Oct 24 21:19:56 <dm8tbr> mranostay: how about a troll-counter after the geiger counter. it would likely go off the scale in here at times though.
Oct 24 21:21:54 <mranostay> how do i measure that in microsiverts?
Oct 24 21:22:41 <mranostay> a mru particle is 20 times more damaging than a _av500_ ray?
Oct 24 22:03:07 <ds2> seriously need to design OUT the EEPROM
Oct 24 22:03:23 <ds2> it is just a bad example given that this is suppose to be a "SoC"
Oct 24 22:07:13 <alan_o> So what is this EEPROM deal anyway.....
Oct 24 22:09:20 <ds2> the 33x EVM is brain dead so it uses the EEPROM to configure itself
Oct 24 22:09:37 <ds2> the Bone is more or less a stripped down EVM design so it too uses the EEPROM
Oct 24 22:10:25 <alan_o> hmm
Oct 24 22:10:29 <alan_o> that's done by the bootloader?
Oct 24 22:10:32 <alan_o> or it's done in ROM?
Oct 24 22:11:29 <ds2> bootloader
Oct 24 22:11:31 <ds2> and kernel
Oct 24 22:11:40 <ds2> the boardfile is marred by EEPROM crap
Oct 24 22:15:07 <alan_o> You mean the EEPROM that tells what kind of board it is?
Oct 24 22:15:24 <ds2> that and what is on the board
Oct 24 22:15:42 <ds2> you can almost build the DTB from the EEPROM
Oct 24 22:42:39 <_av500_> DT was invented my EEPROM vendors in order to sell more .....
Oct 24 22:59:09 <mranostay> _av500_: pub rumours?
Oct 24 23:45:06 <mdp> ds2, the only data used from the eeprom anywhere is the board name and version string
Oct 24 23:46:28 <alan_o> That's consistent with what I saw when looking through the board file a little while ago
Oct 24 23:46:51 <mdp> u-boot uses only the name string both on the vendor tree and mainline
Oct 24 23:47:06 <mdp> mainline kernel doesn't use it at all since there's no board file
Oct 24 23:47:27 <mdp> but the vendor kernel sets up for the old vs. new bone based on the version string
Oct 24 23:48:12 <mdp> oh, sorry, the vendor kernel also uses the kooky options field to figure out what stack of crappy boards is plugged into the evm
Oct 24 23:50:27 <mdp> it's not exactly a bizarre design decision when you have a modular board stack and need to runtime detect what is there
Oct 24 23:51:51 <mdp> we had a magic board id register on all our vme/cpci modular boards that was useful for running a single PReP image on all 15 or so shipping designs.
Oct 24 23:51:58 <mdp> in a previous life
Oct 24 23:58:21 <ds2> bah modular
Oct 25 00:00:28 <mdp> nobody passed a law requiring an eeprom on a design
Oct 25 00:00:59 <ds2> other then the provided code does
Oct 25 00:02:25 <mdp> that's just silly
Oct 25 00:02:50 <ds2> anyways... I'll wait for working PM
Oct 25 00:03:22 <mdp> I hear our s/w team in india is working on it
Oct 25 00:03:39 <ds2> hahaahahah
Oct 25 00:03:53 <ds2> last I heard, there is a fatal silicon bug
Oct 25 00:04:05 <mdp> dunno, not in the loop
Oct 25 00:04:48 <ds2> I'll stick with the 35x or 37x for the time being
Oct 25 00:06:33 <mdp> anything could have a fatal silicon bug, I suppose
Oct 25 00:06:36 <mdp> who knows
Oct 25 00:07:43 <ds2> *nod*
**** ENDING LOGGING AT Thu Oct 25 03:00:00 2012