**** BEGIN LOGGING AT Sun Jan 27 02:59:59 2013
Jan 27 04:38:46 <toneeee> I could use a sloppy burger with katsup and mustard and pickles right now.
Jan 27 12:28:27 <Vij> I'm trying to boot 3.8 kernel on the Beagle bone board
Jan 27 12:28:59 <Vij> Cloned the kernel from the github
Jan 27 12:30:25 <Vij> built the kernel as per the README
Jan 27 12:32:09 <Vij> built uImage and am335x-bone.dtb
Jan 27 12:32:34 <Vij> but when tried to boot the Beagle bone, I get this error:
Jan 27 12:32:53 <Vij> Loaded environment from uEnv.txt Importing environment from mmc ... Loading file "/boot/uImage" from mmc device 0:2 xxa2 4473952 bytes read ## Booting kernel from Legacy Image at 80007fc0 ...    Image Name:   Linux-3.8.0-rc5-00300-g32593d5    Image Type:   ARM Linux Kernel Image (uncompressed)    Data Size:    4473888 Bytes = 4.3 MiB    Load Address: 80008000    Entry Point:  80008000    Verifying Checksum ... OK    XIP Kernel Image ... 
Jan 27 12:33:18 <Vij>  ID (hex)        NAME ffffffff        Generic OMAP4 (Flattened Device Tree) ffffffff        Generic AM33XX (Flattened Device Tree) ffffffff        Generic OMAP3-GP (Flattened Device Tree) ffffffff        Generic OMAP3 (Flattened Device Tree) 0000060a        OMAP3 Beagle Board 00000a9d        IGEP OMAP3 module 00000928        IGEP v2 board 00000ae7        OMAP4 Panda board  Please check your kernel config and/or bootloader.
Jan 27 12:33:27 <Vij> any thoughts
Jan 27 12:33:32 <dm8tbr> yes
Jan 27 12:33:35 <dm8tbr> get a pastebin
Jan 27 12:38:04 <Vij> Hi dm8tbr, what is pastebin?
Jan 27 12:38:53 <dm8tbr> http://bit.ly/An1ss2
Jan 27 12:41:06 <koen> Vij: it looks like you didn't use configs/beaglebone as a config
Jan 27 12:41:44 <koen> Vij: if you did, did you make uboot load the dtb as well?
Jan 27 12:41:57 <koen> if not, try using the uImage-dtb with appended dtb
Jan 27 12:42:43 <Vij> Hi Koen, I've used the beaglebone config
Jan 27 12:43:37 <Vij> I've copied the uImage and am335x-bone.dtb to /boot
Jan 27 12:45:01 <Vij> Is there any other u-boot that does not check for device ID?
Jan 27 13:11:49 <koen> Vij: have a look at the README.md to see how to load the dtb from uboot
Jan 27 13:12:09 <koen> Vij: you'll need a recent uboot, though, it will be easier to use the appended dtb option
Jan 27 13:12:31 <koen> e.g. use arch/arm/boot/uImage-dtb.am335x-bone as uImage
Jan 27 13:27:59 <Vij> thanks koen.
Jan 27 13:28:21 <Vij> Let me check the README again and try that out tomorrow
Jan 27 14:54:15 <keesj> can I driver a led directly from the beagle xm? the on-board leds have an additional pnp circuit
Jan 27 14:55:43 <koen> keesj: depends on the amount of mA you want to draw
Jan 27 14:55:58 <koen> keesj: iirc the xM pins max out at 6mA/1.8V
Jan 27 14:56:02 <koen> should be in the srm
Jan 27 15:06:21 <keesj> your nthere is an "expansion voltage (1.8V) with 30 mA. I did not find a more specific thing about the SoC
Jan 27 15:15:51 <koen> that 30mA might be the 1.8V regulator
Jan 27 15:15:58 <koen> the pins are easy to blow up
Jan 27 15:24:26 <keesj> I might put an arduino in between (might work on 3.3 volt input mode)
Jan 27 15:29:15 <Vij> Can someone please help me understand what is dtb? Why was it not present is 2.6.xx . I'm sorry i'm asking a very silly question here..,
Jan 27 15:29:38 <Vij> I'm new for Linux 3.x
Jan 27 15:30:45 <keesj> best is to read a bit about the device tree. but for short
Jan 27 15:31:16 <keesj> the device tree gives a database to the kernel so it knows what hardware to find
Jan 27 15:31:56 <keesj> (when there is no self describing bus like usb or pci)
Jan 27 15:32:44 <woglinde> vij than you are on the wrong channel
Jan 27 15:32:45 <keesj> there used to be "board" files that created structure in the kernel and every kernel was custom built for the hardware
Jan 27 15:34:03 <Vij> ok
Jan 27 15:34:38 <Vij> thanks Keesj
Jan 27 15:34:38 <woglinde> Vij better google for linux devicetree and boardfile
Jan 27 15:35:28 <Vij> Will do that right away and try to understand. Thanks woglinde.
Jan 27 21:01:01 <prjkt> hi - am i interpreting this correctly http://www.hbrobotics.org/wiki/index.php5/Beagle_Board#Why_choose_the_BeagleBoard_and_OpenCV.3F as beagleboard having DSP meaning hardware acceleration for opencv?
Jan 27 21:01:33 <prjkt> exynos4412 quad
Jan 27 21:01:45 <prjkt> sorry the second line was a mistake
Jan 27 21:02:20 <woglinde> ?
Jan 27 21:02:34 <woglinde> beaglebaords have no exynos4412
Jan 27 21:04:25 <prjkt> this was a mistake, sorry
Jan 27 21:04:33 <prjkt> how is opencv acceleration, anyone know?
Jan 27 21:09:26 <woglinde> did not get some love in the last time
Jan 27 21:09:31 <woglinde> but might work
Jan 27 21:17:44 <tecknikus> hello everyone
Jan 27 21:23:28 <woglinde> hello
Jan 27 21:27:10 <tecknikus> has anyone run a website from the      beagle board
Jan 27 21:28:13 <woglinde> ?
Jan 27 21:34:32 <mrpackethead_> i've got a web server running on my beaglebone
Jan 27 21:34:41 <mrpackethead_> but not an entire web site, no
Jan 27 21:34:55 <mrpackethead_> but it is probably fesible.
Jan 27 21:36:54 <mru> possible but hardly recommended
Jan 27 21:37:37 <tecknikus> i am trying to have a server with less than 5V power... possibly solar
Jan 27 21:38:04 <mru> 5V is not a measure of power
Jan 27 21:38:52 <tecknikus> does  anyone have a running version?
Jan 27 21:39:23 <mru> it's just another linux system
Jan 27 21:39:24 <tecknikus> how much would you charge for the debugged code?
Jan 27 21:39:26 <woglinde> of solar?
Jan 27 21:39:34 <woglinde> no
Jan 27 21:39:47 <mru> any constraints on panel size?
Jan 27 21:40:17 <tecknikus> yeah. I understand people can  sell linux code so long as they include the code
Jan 27 21:40:27 <mrpackethead_> sorry, what are you wanting?
Jan 27 21:40:30 <mrpackethead_> a web server?
Jan 27 21:40:30 <tecknikus> uh, well power constraint
Jan 27 21:40:34 <mrpackethead_> on your beagle?
Jan 27 21:40:51 <tecknikus> yeah an IRC webserver
Jan 27 21:41:00 <mru> now you're making even less sense
Jan 27 21:41:12 <mrpackethead_> tecknikus: theres plenty of good webservers avaialbe.
Jan 27 21:41:17 <mrpackethead_> for free
Jan 27 21:41:24 <mrpackethead_> just download one
Jan 27 21:42:10 <tecknikus> but if you process at higher rates the battery would drain
Jan 27 21:42:14 <woglinde> I think he has some product idea but no clue
Jan 27 21:42:25 <mru> woglinde: I'm not so sure
Jan 27 21:42:29 <toneeee> koen: http://hipstercircuits.com/?p=245#comment-206   did you see this addition/comment from XorA's workflow? Works like a charm.
Jan 27 21:42:34 <toneeee> and I don't have to document a thing :D
Jan 27 21:43:04 <woglinde> hipstercurcuits
Jan 27 21:43:06 <woglinde> woaha
Jan 27 21:43:44 <tecknikus> maybe it is what I am lookinng  for... hmm thanks!
Jan 27 23:12:49 <mranostay> who let  alan_o in here again? :)
Jan 27 23:14:09 <mru> who let him out?
Jan 27 23:14:41 <alan_o> hehe
Jan 27 23:14:56 <alan_o> haven't been kick-banned yet.
Jan 27 23:15:03 <alan_o> one day soon maybe
Jan 27 23:15:18 <mru> you haven't be to #rpi yet?
Jan 27 23:15:43 <mranostay> heh
Jan 27 23:15:44 <alan_o> I lurked there for a few minutes a couple times. seemed boring
Jan 27 23:15:57 <alan_o> nothing good when I've been there
Jan 27 23:16:26 <alan_o> Let's see what's going on over there now......
Jan 27 23:16:58 <mranostay> after wearing earmuffs for two hours my ears are still plugged..
Jan 27 23:17:37 <alan_o> hey mru, it says there's a raspberrypi-owners channel now, for "uncensored Raspberry-pi chat"
Jan 27 23:17:45 <alan_o> oh, only 5 users
Jan 27 23:17:48 <alan_o> nevermind
Jan 27 23:19:22 <mranostay> hmm rpi nudity?
Jan 27 23:19:26 <mrpackethead_> Raspberry PI users are not likely to know how to spell IRC, let alone that it exisits.. there will be flash based chat on some server somewhere
Jan 27 23:20:01 <alan_o> mrpackethead_: there are 2.5x the number of people there as here
Jan 27 23:20:20 <mrpackethead_> i just had a look
Jan 27 23:20:23 <mrpackethead_> and there was 2 people
Jan 27 23:20:25 <mrpackethead_> :-)
Jan 27 23:20:32 <mrpackethead_> so are most of the people here, not actually people?
Jan 27 23:20:34 <alan_o> mrpackethead_: it's #raspberrypi
Jan 27 23:20:56 <alan_o> mrpackethead_: but everyone here seems to abbreviate it :)
Jan 27 23:21:04 <mru> mrpackethead_: most of the people here are actually trolls
Jan 27 23:21:13 <alan_o> (and I always have to look it up, because I can't remember)
Jan 27 23:21:30 <mrpackethead_> the remaining are hobbits, a few elves
Jan 27 23:27:24 <alan_o> so I'm reading the TRM on gpio interrupts, and I'm having a hard time seeing how that fits with what's in the kernel.
Jan 27 23:28:10 <Russ> alan_o, which part?
Jan 27 23:28:30 <alan_o> so in the TRM there are two interrupts for each GPIO bank
Jan 27 23:28:46 <alan_o> and I thought I heard somewhere that only one line per bank can have an intterupt.
Jan 27 23:28:53 <alan_o> not sure where, and I can't find that in the TRM
Jan 27 23:28:56 <alan_o> so maybe that's wrong
Jan 27 23:29:08 <Russ> pretty sure that's wrong
Jan 27 23:29:32 <alan_o> let me check some code to make sure I get the rest of this right...
Jan 27 23:30:33 <alan_o> ok, so I can call request_irq(gpio_to_irq(GPIO_NUM))
Jan 27 23:30:36 <alan_o> and that works
Jan 27 23:30:40 <alan_o> but
Jan 27 23:30:50 <alan_o> best I can find, gpio_to_irq is a no-op for omap
Jan 27 23:30:56 <alan_o> either that or my grep-fu fails me
Jan 27 23:30:57 <Russ> you want to request the gpio first just to be sane
Jan 27 23:31:05 <Russ> I think your grep fu fails you
Jan 27 23:31:11 <alan_o> hmm.
Jan 27 23:32:25 <alan_o> I don't see it defined under mach-omap2/
Jan 27 23:32:57 <alan_o> which lead me to believe that it was using the one in arm/ which is a no-op, but again, I don't see how that can be right, so I'm probably missing it.
Jan 27 23:33:05 <Russ> did you check plat-omap?
Jan 27 23:33:21 <alan_o> no, checking
Jan 27 23:34:01 <alan_o> hmm, not in there either
Jan 27 23:34:35 <Russ> I see it defined in arch/arm as __gpio_to_irq
Jan 27 23:34:41 <Russ> which is in drivers/gpio/gpiolib.c
Jan 27 23:35:02 <alan_o> oh yeah, this is ringing a bell....
Jan 27 23:35:44 <alan_o> right
Jan 27 23:36:04 <alan_o> and then that comes from chip->to_irq() which I can assume is implemented by the GPIO driver for omap
Jan 27 23:36:12 <Russ> gpio_2irq
Jan 27 23:36:18 <Russ> which is bank->irq_base + offset
Jan 27 23:37:54 <alan_o> hmm
Jan 27 23:37:57 <alan_o> base + offset
Jan 27 23:38:11 <alan_o> I wonder if that's in the datasheet instead of the TRM
Jan 27 23:38:39 <Russ> ?
Jan 27 23:38:50 <Russ> I'm not sure if you understand interrupts trees
Jan 27 23:38:59 <Russ> omap really only has one interrupt, intc
Jan 27 23:39:08 <alan_o> Russ: I guess I don't
Jan 27 23:39:14 <mranostay> hey Russ-o
Jan 27 23:39:27 <Russ> each irq bank is its own interrupt chip as well
Jan 27 23:39:55 <Russ> see in gpio-omap.c 'static struct irq_chip gpio_irq_chip'
Jan 27 23:40:15 <alan_o> oh... I see
Jan 27 23:40:19 <alan_o> figure 6-3 in TRM
Jan 27 23:40:29 <alan_o> "nested IRQ"
Jan 27 23:40:35 <alan_o> right?
Jan 27 23:40:38 <Russ> ya
Jan 27 23:40:43 <Russ> remember whos line is it anyway?
Jan 27 23:41:12 <alan_o> yes
Jan 27 23:41:21 <Russ> welcome to modern interrupts, where everything's made up and the irq numbers don't matter
Jan 27 23:41:32 <alan_o> ah
Jan 27 23:41:33 <Russ> hey mranostay
Jan 27 23:41:44 <alan_o> and enter devicetree, a static map of magic numbers :)
Jan 27 23:42:14 <Russ> your gpio could then hook into an i2c io expander that can provide a unique irq for each one of it's io's
Jan 27 23:42:31 <alan_o> Russ: so that's the end game here, to figure out which irq number to put into the device tree for gpio/interrupt.
Jan 27 23:42:33 <Russ> gpio goes high, i2c query's the chip to find out which gpio line changed, etc
Jan 27 23:42:43 <alan_o> hmm.
Jan 27 23:42:59 <Russ> I would have hoped that DT would have moved beyond simple irq numbers :(
Jan 27 23:43:10 <alan_o> I need to read ch 6 more closely then and spend some time in gpio-omap.c
Jan 27 23:43:22 <Russ> alan_o, just cat /proc/interrupts
Jan 27 23:46:16 <alan_o> Russ: so I have a small list of irqs in /proc/interrupts
Jan 27 23:46:29 <alan_o> what am I supposed to be finding here?
Jan 27 23:46:52 <alan_o> those are only the ones that are requested, iirc
Jan 27 23:48:31 <alan_o> maybe it's at91 that had something screwy with gpio/interrupts and 1-per-bank.
Jan 28 00:02:22 <Russ> alan_o, does it list the gpio bank?
Jan 28 00:04:19 <alan_o> Russ: http://dpaste.org/uIZKC/   doesn't look like it, unless there's something else I don't get yet.
Jan 28 00:06:26 <alan_o> I feel like I'm needing to make a static entry in the DT for something that's dynamic. Even if I find out what it is right now, that doesn't mean it will be the same on the next rev of the board, or if someone installs another cape that dynamically registers interrupts
Jan 28 00:09:19 <Russ> have you read this? http://devicetree.org/Device_Tree_Usage#How_Interrupts_Work
Jan 28 00:10:19 <alan_o> I think so. I'll read it again, now with hopefully more understanding.
Jan 28 00:14:33 <mranostay> alan_o: you need more exact steps?
Jan 28 00:14:50 <alan_o> mranostay: yes, please :-D
Jan 28 00:15:16 <alan_o> I think I'm seeing this now
Jan 28 00:15:44 <alan_o> in am33xx.dtsi, gpio1 _is_ an interrupt controller
Jan 28 00:16:41 * Russ gets grumpy with his si units package '15 mΩdash40 mΩ'
Jan 28 00:17:28 <alan_o> maybe panto can read that
Jan 28 00:28:20 <toneeee> Russ: I'll read it, thanks
Jan 28 01:19:17 <mrpackethead_> did a goblin get the master troll
Jan 28 02:05:23 <alan_o> so mranostay, to get the geiger cape to work in the latest kernel, do you have to renumber slot@5 to slot@0 (or slot@n where n < 4) ?
Jan 28 02:05:43 <alan_o> I'm assuming that the overrides are in there because it doesn't support the eeprom, right?
Jan 28 02:07:30 <mranostay> alan_o: no they aren't real slots so no
Jan 28 02:07:42 <mranostay> well with the overrides
Jan 28 02:07:52 <alan_o> ok, so you turn it on from the command line?
Jan 28 02:13:17 <alan_o> I thought I read that it was possible to bind them from sysfs
Jan 28 02:13:20 <alan_o> but I can't see it
Jan 28 02:15:44 <alan_o> ok, I see it now, write to slots in sysfs.
Jan 28 02:16:02 <alan_o> now to determine the syntax from the code
Jan 28 02:19:20 <alan_o> hey, that loaded my driver
Jan 28 02:19:22 <alan_o> than stackdumped :(
Jan 28 02:19:36 <alan_o> looks like I didn't crack the code on the interrupts yet
Jan 28 02:29:26 <alan_o> argh... gpioN is off-by-one in the DT.
Jan 28 02:40:36 <mrpackethead_> i'm getting some actions i cant understand with the ephpwm ports..
Jan 28 02:40:42 <mrpackethead_> set a duty_percent
Jan 28 02:40:48 <mrpackethead_> on one port
Jan 28 02:40:52 <mrpackethead_> and another one changes.
**** ENDING LOGGING AT Mon Jan 28 03:00:00 2013