[02:16] <TheUni> rsalveti: ping
=== asac_ is now known as asac
=== ogra_ac is now known as ogra_
[13:05] <lil_pete> hey guys can somebody explain to me how opengl works / is supposed to work when combined with framebuffer-drivers? (nvidia tegra board)
[14:30] <ppisati> GrueMaster: ping
[15:42] <GrueMaster> ppisati: pong
[15:45] <ppisati> GrueMaster: LP#586386
[15:45] <ppisati> bug 586386
[15:45] <ubot2> Launchpad bug 586386 in linux-ti-omap4 "Kernel should hand over all cmdline args to the init environment" [Medium,Fix committed] https://launchpad.net/bugs/586386
[15:46] <ppisati> the option is there, but it doesn't spwan any getty at boot
[15:46] <ppisati> maverick, omap4
[15:46] <GrueMaster> Not sure, but I think that was fixed.
[15:46] <ppisati> GrueMaster: ok, move it to fix-released then
[15:46] <GrueMaster> Need to double check with ogra.
[15:47] <ppisati> GrueMaster: but in my case, if i don't add the tty[OS]2 in /etc/init, i don't get any console
[15:47] <GrueMaster> ogra_: ^^^
[15:47] <ppisati> GrueMaster: bug 672635
[15:47] <GrueMaster> That's a different issue I believe.
[15:47] <ubot2> Launchpad bug 672635 in linux-ti-omap4 "enable CONFIG_SCSI_MULTI_LUN" [Medium,Fix committed] https://launchpad.net/bugs/672635
[15:47] <ppisati> the same, the option is there
[15:47] <GrueMaster> And I tested it.
[15:47] <ppisati> k, -> fix released
[15:51] <ppisati> btw, do we the datasheet for these chips?
[15:54] <GrueMaster> I wouldn't know.
=== prpplague^2 is now known as prpplague
=== apachelogger is now known as javalogger
[20:45] <robclark> rsalveti, is drivers/gpu/pvr moving in to kernel tree?  Or did I misunderstand?
[20:45] <rsalveti> robclark: not for ubuntu, we're still working as a separated module
[20:45] <robclark> ahh, ok.. so same as before
[20:46] <rsalveti> robclark: don't know if the ti android kernel maintainers are planning to push that upstream
[20:46] <rsalveti> probably not
[20:46] <robclark> it isn't really upstreamable..
[20:46] <rsalveti> yeah, so it'll probably stay as it is now
[20:46] <robclark> but it is quite convenient to have it not as out-of-tree
[20:46] <robclark> (the only thing I like about android kernel)
[20:47] <GrueMaster> Only thing?  How about...er...ok I'll give you that one.  :P
[21:26] <michaelh1> Hi there.  Sorry for the newbie question, but I have a netboot/NFS root setup and I'd like to build my own Panda kernel with the right things compiled in.  Where should I start?
[21:27] <michaelh1> (I need the Ubuntu kernel to get the command line MAC address setting)
[21:43] <GrueMaster> The easiest way to start is to use the Ubuntu kernel config and change the settings you need.  Then everything else will just work.
[21:54] <michaelh1> GrueMaster: thanks.  So I start with kernel.org/.../ubuntu-maverick.git on the omap4 branch?  Where does the .config live?
[21:55] <GrueMaster> Not sure.  I only do image testing.  rsalveti?
[21:55] <GrueMaster> You could also look up the ubuntu kernel build process on the wiki.
[21:56] <GrueMaster> https://wiki.ubuntu.com/Kernel/
[21:58] <rsalveti> michaelh1: do you need the maverick one?
[21:58] <rsalveti> or nattys?
[21:58] <michaelh1> rsalveti: sorry, natty.  Typo.
[21:59] <rsalveti> michaelh1: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=summary
[21:59] <rsalveti> branch ti-omap4
[21:59] <michaelh1> rsalveti: I'd like to use the Linaro one but I need a fixed MAC address.  I haven't/didn't want to open that can of worms...
[22:00] <rsalveti> michaelh1: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=blob;f=debian.ti-omap4/config/config.common.ubuntu;h=f3d9425065695f7698f71d4222d5427268abe551;hb=refs/heads/ti-omap4
[22:00] <rsalveti> the config file
[22:00] <michaelh1> rsalveti: OK.  Copy that to .config, make oldconfig, make menuconfig
[22:00] <rsalveti> michaelh1: yup
[22:00] <michaelh1> rsalveti: what's the story with using the full 1 GB of RAM these days?
[22:01] <rsalveti> michaelh1: still not fixed I believe, but didn't test with latest one yet
[22:01] <michaelh1> OK.  Can I use more than 460 MB?
[22:01] <rsalveti> I remember the issue was still there at the time of rc6, rc7
[22:01] <rsalveti> 768 should be ok
[22:02] <michaelh1> mem=768 or some type of split mem=460, mem=256@xyz?
[22:02] <rsalveti> if you're not using any gst with ducati
[22:02] <rsalveti> michaelh1: the split is to leave some mem to ducati
[22:02] <rsalveti> you can just use 768 directly if you're not using it
[22:02] <michaelh1> Ah.  These are headless so I'll drop it.
[22:04] <michaelh1> Sorry again.  git clone git://kernel.ubuntu.com/ubuntu/ubuntu-natty.git has completed.  'git branch' only lists master.  How do I select the ti-omap4 branch?
[22:07] <rsalveti> michaelh1: git remote -a should list the remote branches
[22:08] <rsalveti> then just give git branch ti-omap4 remotes/origin/ti-omap4
[22:08] <rsalveti> and with --track if you still want to use pull on it
[22:09] <michaelh1> Ah, success.  Thanks.  For some reason git 1.7.1 (Maverick) doesn't have git remote -a.
[22:10] <michaelh1> rsalveti: is this written up somewhere?  Otherwise I'll blog it so I remember it...
[22:11] <rsalveti> michaelh1: don't know if it's posted somewhere already, just blog it :-)
[22:11] <michaelh1> rsalveti: will do
[22:41] <michaelh1> Hmm.  All of my PandaBoards end up with the same MAC address of 72:b9:94:3b:51:04
[22:45] <rsalveti> michaelh1: you can change that by a module parameter or by changing using normal debian tools
[22:46] <michaelh1> rsalveti: the old .macaddr module parameter has gone away.  I'm doing NFS root with no uInitrd so it has to be done in the kernel.
[22:47] <rsalveti> I think the parameter is still working with our kernel
[22:47] <michaelh1> rsalveti: the code for smsc95xx.macaddr=xxx is gone.  There seems to be something re: USBNET_PLATDATA_FLAG__USE_MAC but I'm still tracking it down...
[22:48] <michaelh1> rsalveti: the function smsc95xx_is_macaddr_param() is gone as is the module parameter macaddr in drivers/net/usb/smsc95xx.c
[22:49] <rsalveti> michaelh1: yeah, it's applied but then reverted: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=commitdiff;h=4c35e56b6bd6a8f372e24c4ed21dc4bce6e7c444;hp=497525b16697ed40b8e4c2bcc2b634472f6a663d
[22:49] <michaelh1> Huh, not the most useful comment.  Once you've got userspace you can probably fix this.
[22:51] <rsalveti> michaelh1: hm, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=commitdiff;h=6114ac31d9805956f6115d4eceba78edd03a8792;hp=321610a00ebdfacc6df4c7537626ab03ec0278b5
[22:51] <rsalveti> it should be "unique"
[22:53] <rsalveti> at least with our latest kernel
[22:53] <GrueMaster> The trick is to see if it is persistent & unique.
[22:54] <michaelh1> OK.  Same uImage, different boards.  Here's board 1: [    6.402801] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 72:b9:94:3b:51:04
[22:54]  * michaelh1 swaps boards
[22:56] <michaelh1> [    7.566955] smsc95xx 1-1.1:1.0: eth0: register 'smsc95xx' at usb-ehci-omap.0-1.1, smsc95xx USB 2.0 Ethernet, 72:b9:94:3b:51:04
[22:56] <rsalveti> so it's not working :-)
[22:58] <GrueMaster> Well, not to the depth required.  Not sure how it is getting this data, but if it is using something from the cpu that is burned in at wafer fab time, it could be unique to each wafer.
[22:58] <GrueMaster> Not as rare in a multiplatform deployment, but still enough for normal usage.
[22:59] <rsalveti> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=commitdiff;h=321610a00ebdfacc6df4c7537626ab03ec0278b5;hp=ed89bb009173a8a4bf0567311e616a6100b1353f
[23:00] <michaelh1> Yip.  I see in struct platform_async_platform_data panda_async_pdata_map that it refers to usb1/1-1/1-1.1 and this seems to be usb1/1-1/1-1.0
[23:04] <michaelh1> Hacking it and setting .device_path = "usb1/1-1/1-1.0" gives unique MAC addresses...
[23:04] <GrueMaster> Heh.  I'd like to see them use 00-00-36 as the starting mac address.
[23:05] <michaelh1> Hmm?  It's currently in the 80:xxx series which are private...
[23:05] <GrueMaster> (sorry, was looking at the ieee mac oui database.  That was for Atari.  </geek-moment>)
[23:06] <michaelh1> Heh.  Disregard the above - I've now broken it as the MAC addresses are now random.  It seems the 1.1 was right, but the addresses are not unique.
[23:11] <rsalveti> michaelh1: makes sense, now why die_id is the same for all your pandas I'm not sure
[23:12] <michaelh1> I just printed out the die ID and they're identical: 1b95c d00f0451 1140 0 (four hex words)
[23:18] <michaelh1> tap_base is fc002000.  Is that correct?
[23:34] <michaelh1> Huh, id.c seems to be wrong.  According to the TRM, the DIE ID is at 208, 20C, 210, and not 218, 21c, 220.  It's actually reading the product ID which is why it's consistent.
[23:37] <rsalveti> michaelh1: cool
[23:39] <michaelh1> Right, I have a hack-around.  I can't find the die ID in the OMAP3 manual to see if it's always been wrong.
[23:43] <michaelh1> Huh.  The die IDs are a6caea0 0 105e0023 300f0 and a6caea0 0 105e0023 300f0 so only id_2 is unique...
[23:52] <michaelh1> Hmm.  mem=768M causes a halt at early boot: http://pastebin.ubuntu.com/586652/
[23:54] <rsalveti> michaelh1: weird, let me check the options
[23:54] <michaelh1> I have: "console=tty0 console=ttyO2,115200n8  root=/dev/nfs earlyprintk fixrtc nocompcache vram=0 mem=768M ip=dhcp"
[23:54] <rsalveti> I also have mem=768M@0x80000000 but not using the latest kernel, still 2.6.38-1206-omap4
[23:55] <rsalveti> and here it's working fine, let me upgrade it
[23:57] <michaelh1> Does it interact with u-boot any?
[23:59] <michaelh1> mem=512M works, mem=520M doesn't, u-boot claims 512 MB of RAM
[23:59] <rsalveti> hm, maybe your x-loader?
[23:59] <michaelh1> I'll replace MLO and u-boot and see what happens...
[23:59] <rsalveti> I believe we're using latest linaro's u-boot