[05:57] <ukleinek> ericm|ubuntu: oh, you're reading lkml
[06:00] <ukleinek> ericm|ubuntu: and I would welcome some common practise, Linus, too, I guess
[06:27] <ericm|ubuntu> ukleinek, replied
[06:43] <ukleinek> ericm|ubuntu: oh, missed the __initdata
[06:44]  * ukleinek is away, the children are up, so time for breakfast
[07:20] <ukleinek> ericm|ubuntu: what do you need .dev_name for?
[07:20] <ericm|ubuntu> ukleinek, nothing - just to distinguish between dev_name and drv_name :-)
[07:23] <ericm|ubuntu> ukleinek, I hope in the end I can use dev_name only - when all platform driver accepts a list of supported platform_device_id[]
[07:55] <ukleinek> ericm|ubuntu: why is platform_device_id[] better than a dev_name?
[07:56] <ukleinek> ericm|ubuntu: just to let you know, this is how I register devices on imx (currently)
[07:56] <ukleinek> http://article.gmane.org/gmane.linux.ports.arm.kernel/83340
[07:57] <ukleinek> http://article.gmane.org/gmane.linux.ports.arm.kernel/83342
[07:59] <ukleinek> 83285 is more interesting than 83342 though
[08:10] <ukleinek> ericm|ubuntu: regarding "Introduce 'struct machine_class' for SoC level abstraction", do you really want to have boot_params in struct machine_class?  I didn't recheck, but isn't that legacy cruft?
[08:11] <ukleinek> (i.e. for platforms not passing r2)
[08:24] <ericm|ubuntu> ukleinek, well - I don't like that either - but for backward compatiblity consideration, it can be removed later as well
[08:35] <hrw> morning
[08:36] <lag> Morning hrq
[08:36] <lag> Grrrr
[08:36] <lag> Morning hrw!
[09:58] <hrw> ogra: hi
[10:29] <ogra_cmpc> cooloney, does the new omap4 package have the videoram fixes from TI so we can actually boot with a screen ?
[10:31] <cooloney> ogra_cmpc: oh, no,
[10:31] <cooloney> ogra_cmpc: is there any bug about that videoram issue?
[10:32] <cooloney> ogra_cmpc: i can talk with sebjan about that
[10:33] <ogra_cmpc> cooloney, there isnt a bug, i think sebjan's tree has the fix though, vram needs to be 32M instead of 8
[10:33] <hrw> my first gfx card had 2MB ram...
[10:34] <ogra_cmpc> well, your first gfx card dint have three different outputs i guess :) each needs 8M
[10:34] <hrw> yep - vga only
[10:34] <hrw> and I used 1152x864-16 with it
[10:34] <ogra_cmpc> wow
[10:35] <ogra_cmpc> my first gfx card didnt do more than 640x480
[10:35] <ogra_cmpc> and that was an expensive one back then
[10:35] <hrw> ogra: it was 2000
[10:35] <hrw> pci ati mach64 card which was quite obsolete at that time
[10:35] <ogra_cmpc> yeah, mach64 cards didnt exist when i started
[10:36]  * ogra_cmpc isnt even sure ati existed back then
[10:36] <cooloney> ogra_cmpc: http://kernel.ubuntu.com/git?p=roc/ubuntu-maverick.git;a=commitdiff;h=5c5862e6dfc3a46e72d82c46ea8534b38c4ac3a8
[10:36] <cooloney> ogra_cmpc: is this commit which will fix this issue?
[10:36] <cooloney> i am not sure about that, since there is no bug information in the commit log
[10:37] <hrw> ogra: at same time I had Hyundai 386sx/25MHz with ati onboard graphics. but we used only 720x480 mode for text console with it
[10:38] <ogra> cooloney, hmm, afaik it was just a config option
[10:39] <cooloney> ogra: http://kernel.ubuntu.com/git?p=roc/ubuntu-maverick.git;a=commitdiff;h=984ab103c27b1811e05a60e0a1a7129fed3b5250
[10:39] <cooloney> this is the only config change in the commit
[10:39] <ogra> weird
[10:39] <cooloney> but i failed to see any videoram fixes
[10:39] <ogra> there must be a default for VRAM
[10:39] <cooloney> ogra: so the testing kernel fixed that?
[10:39] <ogra> setting that to 32M should fix the display issues
[10:39] <ogra> i havent tested it yet
[10:40] <cooloney> ok,
[10:40] <ogra> setting vram=32M on the cmdline gives me HDMI with all kernels though
[10:40] <cooloney> that's a very useful info
[10:40] <hrw> looking at apt-cross code makes my head explode
[10:42] <sebjan> cooloney: I planned to set the VRAM to 32MB by default in next kernel sometimes this week (not included in the patches you pulled today)
[10:43] <cooloney> sebjan: ok, got it. from ogra's info, HDMI issue can be fixed by that
[10:43] <sebjan> yes, the vram size can be overriden through the command line
[10:53] <cooloney> sebjan: sorry, i am not debugging on it, it seems it doesn't work on lag's side
[10:53] <ogra> cooloney, TI said there might be issues with some monitors
[10:53] <lag> http://www.amazon.co.uk/LG-W2261VP-inch-LCD-Monitor/dp/B0028KGKJA
[10:53] <lag> This is the one I'm using
[10:53] <ogra> funnily ndec said specifically with samsung ... my samsung works fine though
[10:53] <lag> Fairly standard
[10:54] <lag> ogra: What do you see on your monitor?
[10:55] <cooloney> ogra: mine is viewsonice HDMI 1080P, but don't have hardware to test, -:<
[10:55] <ogra> teh kernel messages and some plymouth console errors (as i said my rootfs doesnt work)
[10:56] <ogra> i'll try with a proper rootfs later today
[10:56] <lag> At least you see something
[10:56] <lag> What kernel are you using?
[10:56] <ogra> currently i'm busy getting the omap3 images working at least
[10:56] <ogra> Linux version 2.6.34-900-omap4 (buildd@hubbard) (gcc version 4.4.4 (Ubuntu 4.4.4-4ubuntu1) ) #1-Ubuntu SMP PREEMPT Fri Jun 18 23:51:15 UTC 2010
[10:57] <lag> Same as me
[10:57] <ogra> the latest archive kernel
[10:57] <lag> That sucks :(
[10:57] <ogra> did you try booting without setting a serial console on cmdline
[10:58] <ogra> (your paste chopped off the cmdline string)
[10:58] <lag> setenv bootargs root=/dev/mmcblk0p2 rootwait ro mem=463M console=ttyO2,115200n8 vram=32M; mmcinit 0; fatload mmc 0 0x80200000 uImage; bootm 0x80200000
[10:58] <lag> Fail
[10:58] <ogra> err
[10:58] <ogra> indeed
[10:59] <ogra> console=ttyO2,115200n8 and no other console= option forces serial only
[10:59] <ogra> try dropping all console= options for a start
[10:59] <ogra> that should default to tty0
[10:59] <cooloney> ogra: yeah, i agree
[11:12] <lag> setenv bootargs root=/dev/mmcblk0p2 rootwait ro mem=463M vram=32M; mmcinit 0; fatload mmc 0 0x80200000 uImage; bootm 0x80200000
[11:12] <lag> Fail
[11:12] <ogra> try setenv bootargs root=/dev/mmcblk0p2 rootwait ro mem=463M console=ttyO2,115200n8 console=tty0 vram=32M; mmcinit 0; fatload mmc 0 0x80200000 uImage; bootm 0x80200000
[11:12] <ogra> thats what i used with my last boot
[11:13] <ogra> if that doesnt work, tell ndec that LG monitors have issues too
[11:13] <lag> Tried that already - Fail
[11:13] <lag> I think he would have heard you
[11:13] <lag> ndec: ACK -^
[11:17]  * ogra ponders buying something like http://www.mp3car.com/vbulletin/mp3car-blog-talk/141162-hardware-review-lilliput-669gl-70np-c-t-7-hdmi-monitor.html for travelling
[11:21] <hrw> ogra: to car or for desk?
[11:21] <ogra> for using my omap boards while travelling
[11:21] <ogra> its small enough to fit in a laptop bag along with beagle or panda
[11:22] <hrw> and needs 12V
[11:22] <ogra> comes with power supply
[11:22] <hrw> so you need power socket to use it
[11:22] <ogra> indeed
[11:22] <hrw> dpkg-shlibdeps: error: couldn't find library libc.so.6 needed by debian/libgcc1-armel-cross/usr/arm-linux-gnueabi/lib/libgcc_s.so.1 (ELF format: 'elf32-littlearm'; RPATH: '').
[11:22] <hrw> shit
[11:25] <lag> It's more expensive, but: http://www.cinema5d.com/news/?p=3063
[11:26] <ogra> heh, $600
[11:27] <lag> As I said ...
[11:28] <lool> hrw: Yeah, same thing as last week
[11:28] <lool> hrw: Did you make progress on this issue?  Did you chat with slangasek about it
[11:28] <lag> Probably better to buy a 12v battery pack - not sure how long it would last though
[11:28] <lool> It's quite a subtle issue, and resolution is not easy
[11:29] <hrw> lool: I just got hit by that
[11:29] <ogra> lag, well, i'm more intrested in having a display when sitting in some hotel room at a conference or sprint
[11:29] <ogra> beyond that the lilliput has a touchscreen too :)
[11:29] <lool> hrw: Isn't that the same thing as last week, where we discussed shlibs and building a fake shlibs package?
[11:29] <hrw> lool: no
[11:29] <lag> It looks good, and I'm sure you'd be able to power it if you really wanted to
[11:30] <hrw> lool: thats I have in chroot which has all cross libs installed
[11:30] <lool> hrw: I dont see the difference
[11:30] <lag> (by batteries I mean)
[11:30] <ogra> yeah
[11:30] <lool> hrw: Do you have binutils-multiarch installed?
[11:31] <hrw> yes
[11:40]  * ogra fires off an omap3 livefs build ... 
[11:42] <hrw> lool: I found a bug
[11:42] <hrw> side effect of merging cross rules
[12:24] <lag> Has anyone seen this before? http://paste.ubuntu.com/456338/
[12:30] <lag> ogra -^
[12:31] <ogra_cmpc> lag, nope
[12:31] <ogra_cmpc> but i havent tried the kernele from lucid-proposed
[12:31] <ogra_cmpc> (which you seem to use)
[12:32] <ogra_cmpc> https://edge.launchpad.net/ubuntu/+source/linux-ti-omap/2.6.33-502.8 doesnt really look like there was something added to it that could cause it though
[12:34] <lag> I'm using the kernel from git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git
[12:34] <lag> Is that proposed?
[12:35] <ogra_cmpc> well, 502 is in proposed
[12:35] <lag> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=shortlog;h=refs/heads/ti-omap
[12:36] <ogra_cmpc> 501 was a security update i think
[12:36] <ogra_cmpc> 500 was the release kernel for lucid
[12:36] <ogra_cmpc> your paste has 2.6.33-502-omap
[12:38] <lag> Yes, that's what it says
[12:39] <ogra_cmpc> all i can say is that the 500 kernwel worked fine for me
[12:39] <ogra_cmpc> no idea about the security or proposed versions
[12:39] <lag> Okay, I'll try and find someone who has built the latest kernel
[12:39] <lag> Thanks ogra_cmpc
[12:40] <ogra_cmpc> to be honest i dont really look at lucid atm
[12:42]  * ogra_cmpc sighs about evolution-data-server being out of sync and breaking the images
[13:13] <dcordes> hi
[13:17] <dcordes> using rootstock I created an ubuntu armel rootfs. most stuff works ootb. also networkmanager sets up my usb ethernet device correctly with dhcp. but there is one problem
[13:17] <dcordes> only root can use networking
[13:17] <dcordes> I setup my 'user' ubuntu with all privilges seleectable in the gui but it didn't fix it
[13:18] <dcordes> what could be the cause of the problem ?
[13:24] <lag> ogra_cmpc: Can you email me your Panda kernel which you have HDMI working on please?
[13:27] <ogra_cmpc> lag, its the plain archive kernel
[13:27] <lag> As is mine I think
[13:28] <lag> But I'd like to double-check
[13:28] <lag> I'd like to check all avenues before I say "it's an LG monitor issue"
[13:29] <directhex> how close is qemu-arm-static to the hardware platform ubuntu is compiled for, especially the thumb2 stuff?
[13:44] <ogra> lag, http://people.canonical.com/~ogra/panda/
[13:45] <lag> Thanks ogra
[14:01] <sebjan> cooloney: I tested your image: it boots on my 2 boards. However, the smsc95xx.macaddr parameter does not have any effect, and I can't understand why... (this is the last patch that you pulled)
[14:05] <lag> ogra: That doesn't work either. It must be a problem with LG monitors
[14:05] <ogra> yeah, i suspected that after ndec's comment last week
[14:05] <ogra> seems some EDID's cant be read properly by the driver
[14:06] <lag> That makes sense
[14:06] <lag> It must only be a parsing issue though? No biggy?
[14:10] <hrw> http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ updated to recent compilers
[14:12] <cwillu_at_work> rcn-ee, <3
[14:13] <ogra> lag, probably
[15:41] <directhex> bleh
[17:03] <cwillu_at_work> ogra, do you know anything about x-loader and company?
[17:04] <prpplague> cwillu_at_work: anything in particular you would like to know?
[17:05] <cwillu_at_work> prpplague, background:  I'm trying to rig up an sd card to update nand and poke at a couple odds and ends on a zippy board if and only if the user button is held down
[17:05] <cwillu_at_work> so, I need an x-load that both initializes i2c correctly so that the zippy will work, and which will pull u-boot off nand rather than mmc
[17:06] <cwillu_at_work> apparently the place to set that is in include/configs/omap3530beagle.h
[17:06] <cwillu_at_work> CFG_CMD_MMC   0
[17:06] <cwillu_at_work> except, that doesn't make any difference
[17:07] <cwillu_at_work> it's reading the x-loader off nand (verified with the datestamp), but the option just has no effect
[17:07] <cwillu_at_work> if I boot without the sd card in, it loads u-boot off nand correctly, so it's not that I don't actually have a usable u-boot on there
[17:07] <cwillu_at_work> i.e., I could just kill off MLO from the sd card, and things would work
[17:08] <cwillu_at_work> but I'd lose the ability to use the user button to trigger updating x-load and u-boot to nand
[17:08]  * prpplague reads through and tries to understand your targer
[17:08] <prpplague> target
[17:09] <cwillu_at_work> I don't get what I'm doing wrong though;  as far as I can tell from reading this, setting CONFIG_MMC to 0 should completely remove the code to even attempt to load u-boot from mmc
[17:09] <cwillu_at_work> but yet it _still_ does it
[17:11] <prpplague> cwillu_at_work: hmm, interesting situation
[17:12] <prpplague> cwillu_at_work: i'd have to look at the sysboot configuration on the beagle(its been awhile)
[17:12]  * prpplague pulls the docs
[17:13] <cwillu_at_work> and I've checked the voltages on the user button, it's not broken :p
[17:13] <cwillu_at_work> 1.8v on one side, 0v on the other
[17:13] <cwillu_at_work> and pulled down to 0v when the button is pushed
[17:13]  * cwillu_at_work huggles prpplague 
[17:14] <cwillu_at_work> the odd thing is that there's a version of x-load that works properly re: nand, but it doesn't initialize i2c properly, so u-boot with zippy2 support just hangs
[17:16] <cwillu_at_work> fatload mmc 0 80200000 x-load.bin; nandecc hw; nand erase 0 80000; nand write 80200000 0 20000; nand write 80200000 20000 20000; nand write 80200000 40000 20000; nand write 80200000 60000 20000
[17:16] <cwillu_at_work> is what I'm using to write it
[17:17] <cwillu_at_work> (I've named the file x-load.bin instead of .ift after signing it, as the extra extension triggers the bad behaviour re: requiring MLO to be written first on fat
[17:21] <prpplague> cwillu_at_work: hmm, from what i am seeing, if you have a valid x-load in the nand flash, and the user button is not pressed, it should load the x-load from nand flash, not the sd card
[17:21] <prpplague> cwillu_at_work: is that what you are seeing?
[17:22] <cwillu_at_work> yes
[17:22] <cwillu_at_work> Texas Instruments X-Loader 1.4.4ss (Apr 13 2010 - 22:36:28) with user
[17:22] <cwillu_at_work> Texas Instruments X-Loader 1.4.4ss (Jun 28 2010 - 10:11:02) without
[17:23] <prpplague> ok
[17:23] <cwillu_at_work> both give Loading u-boot.bin from mmc
[17:23] <cwillu_at_work> if I remove the sd card, I get Loading u-boot.bin from nand
[17:23] <prpplague> ahh, ok
[17:23] <cwillu_at_work> and then the u-boot prompt
[17:24] <prpplague> cwillu_at_work: you need to look in the x-load code, there is a order of preference for loading the u-boot.bin file
[17:24] <prpplague> cwillu_at_work: normally it is the sd card file, nand second
[17:24] <cwillu_at_work> prpplague, mmc support isn't even compiled in as far as I can tell
[17:25] <cwillu_at_work> include/configs/omap3530beagle.h is documented as the place to change the ordering
[17:25] <cwillu_at_work> but the setting doesn't affect it
[17:25] <prpplague> that is in the x-loader code?
[17:25] <cwillu_at_work> yes
[17:25] <cwillu_at_work> line 48 should be 1 to boot from mmc, and 0 to boot from nand
[17:26] <cwillu_at_work> I've also tried disabling CONFIG_MMC entirely
[17:26]  * ogra_cmpc thought its a matter of how long you hold down the user button
[17:27] <ogra_cmpc> at least it seems to work that way wiht the ubuntu x-loader here
[17:27] <cwillu_at_work> ogra_cmpc, if I'm not holding the user button down, it shouldn't be loading from mmc
[17:27] <cwillu_at_work> ogra, it's pulling x-loader from nand, but that xloader is just going to mmc
[17:27] <ogra_cmpc> right, but if you hold it down after x-loader is up it should load u-boot from mmc
[17:28] <cwillu_at_work> ogra_cmpc, ...
[17:28] <cwillu_at_work> it's going from mmc even _without_ the user button
[17:28] <ogra_cmpc> right, i got that
[17:28] <cwillu_at_work> the only way it pulls u-boot from nand right now is if I don't put the sd card in at all
[17:28] <ogra_cmpc> weird
[17:29] <cwillu_at_work> yes :)
[17:30] <cwillu_at_work> lib/board.c:91 is where it tries to pull it
[17:30] <cwillu_at_work> and as far as I can tell, that shouldn't even be compiled in (CONFIG_MMC = 0)
[17:31] <prpplague> cwillu_at_work: something doesn't sound right for your configuration and such
[17:31] <prpplague> cwillu_at_work: i just tested on my beagle and it works fine
[17:31] <cwillu_at_work> and you had an otherwise bootable sd card in the beagle?
[17:32] <prpplague> yea
[17:33] <cwillu_at_work> L:/
[17:33] <cwillu_at_work> this is from koen's golden git repo :./
[17:33] <prpplague> cwillu_at_work: i think it might be best if you have the same x-load built from scratch on both the sd and flash
[17:33] <cwillu_at_work> no offense, but how is that relevant?
[17:34] <cwillu_at_work> if the mmc is affecting this, then something is broken
[17:34] <cwillu_at_work> it shouldn't be touching it, and so whatever is on it should be irrelevant
[17:35]  * ogra_cmpc agrees
[17:36] <prpplague> cwillu_at_work: you need to start from a known position, if you have the same code built together at one time, you can use it as a basis for your tests
[17:36] <ogra_cmpc> we're using 1.4.3 from the sarkoman tree in ubuntu btw
[17:38] <cwillu_at_work> prpplague, I'm not going to lie, that's a maddeningly frustrating thing for you to say
[17:39] <cwillu_at_work> I justed deleted MLO and x-load off the sd card completely.
[17:39] <cwillu_at_work> same behaviour
[17:39] <prpplague> cwillu_at_work: interesting
[17:40] <cwillu_at_work> could you send me your copy?  about the only thing left it could be is my build environment and my beagle
[17:40] <prpplague> cwillu_at_work: i'm currently at work and am limited to what i can send you
[17:40] <prpplague> cwillu_at_work: i could post something on the wiki this evening
[17:41] <ogra_cmpc> cwillu_at_work, just grab the ubuntu deb and unpack it if you need a working bainry
[17:41] <ogra_cmpc> *binary
[17:41] <prpplague> http://www.elinux.org/BeagleBoard_Zippy2#Copy_files_onto_the_BOOT_partition
[17:41] <prpplague> ogra_cmpc: have your tried the MLO binary that i already have posted?
[17:41] <ogra_cmpc> nope, i'm not near my beagle
[17:42] <prpplague> oops sorry that was for cwillu_at_work
[17:42] <prpplague> cwillu_at_work: http://www.elinux.org/BeagleBoard_Zippy2#Copy_files_onto_the_BOOT_partition
[17:42] <cwillu_at_work> prpplague, was that MLO built for nand or for MMC though?
[17:44] <cwillu_at_work> ... and all this to avoid teaching a technician how to write the firmware by hand :p
[17:46] <cwillu_at_work> just to check, when you said that you had it working:  you had MLO and u-boot on MMC, and x-loader and u-boot in NAND, and when you booted without the user button held down, you got the message "Loading u-boot.bin from nand"?
[17:46] <prpplague> cwillu_at_work: correct
[17:49] <cwillu_at_work> ... you know what would kinda tick me off?
[17:49] <cwillu_at_work> if the damn signing program was silently not doing anything because of an existing file with the same name, which wasn't getting cleaned by make distclean
[17:51] <prpplague> cwillu_at_work: yea you have to be careful about that
[17:51] <prpplague> and you have to make sure that you copy the x-load.bin.ift to the file name MLO
[17:51] <lag> orga: ping
[17:51] <cwillu_at_work> no, not in this case
[17:52] <cwillu_at_work> MLO is what you call it if you're booting off the sd card
[17:52] <cwillu_at_work> which I'm not (unless the user button is pressed, but that's not where my grief is)\
[17:52] <prpplague> right, with respect to the SD card
[17:53] <cwillu_at_work> nope, that didn't change anything
[17:53] <cwillu_at_work> Texas Instruments X-Loader 1.4.4ss (Jun 28 2010 - 10:50:17)
[17:53] <cwillu_at_work> Loading u-boot.bin from mmc
[17:54] <cwillu_at_work> prpplague, which config options did you have to change in include/configs/omap3530beagle.h?
[17:54] <cwillu_at_work> and then I'll stop bugging you and give up on this for a while :p
[17:55] <lag> ogra_cmpc: ping
[17:55] <prpplague> cwillu_at_work: sorry, i don';t have the source here, i'm currently working onsite for a customer
[20:01] <directhex> sigh. i create an image to run qemu-system-arm, and i'm left with a blinking cursor and no cpu activity. this isn't fun.
[20:53] <prpplague> ogra_cmpc: ping
[20:53] <prpplague> ogra: ping
[20:58] <prpplague> any ubuntu userland folks awake?
[21:00] <GrueMaster> define "awake".  :P
[21:00] <GrueMaster> what's up?
[21:01] <prpplague> GrueMaster: hey, i'm mainly a kernel person, i wonder if you know about running ubuntu userland with multiple framebuffers?
[21:01] <GrueMaster> Hmm.  Not really.  I would think X treats them as separate screens.
[21:02] <prpplague> GrueMaster: that is my thoughts, i was just curious if there were some good examples
[21:02] <GrueMaster> But the only system I have that remotely fits that description is my desktop w/ nVidia graphics.
[21:02] <prpplague> GrueMaster: ahh
[21:02] <GrueMaster> X should detect the outputs.
[21:03] <GrueMaster> I would think it would be similar to a laptop with external video output ports (vga, dvi, s-video).
[21:03] <prpplague> GrueMaster: that was my guess, but some reading online seems to indicate some people have problems with that
[21:03] <GrueMaster> Depends on the card & drivers.
[21:04]  * prpplague will find out soon
[21:04] <GrueMaster> good luck.  post your results.
[21:04] <prpplague> hehe, won't be able to for a while
[21:06] <dcordes> anybody able to comment on my non-root network usage problem ?
[23:30] <dcordes> is it possble to debug qemu during rootstock process ?
[23:31] <dcordes> it seems like it gets stuck on "Switching to Virtual Machine for second stage processing"
[23:31] <dcordes> qemu process eating 100% cpu
[23:31] <dcordes> and mem usage doesn't change
[23:31] <dcordes> last time let it run for 20 minutes
[23:32] <dcordes> without any output. is this high duration without any output expected ?