[05:03] <RobotGuy> I've configured and built a new custom kernel for Ubuntu, but am having difficulty getting it to boot. There is at least one error in the rebuild scrpt in the tools directory - it doesn't pass the correct kernel version (of the new kernel) to the commands. I'm unable to use a keyboard attacked to the Beagle-xM to get more info.
[05:04] <RobotGuy> Kernel drops me to an (initfs) prompt, but I can't enter anything to get more info.
[05:08] <RobotGuy> This is under Maverick 10.10
[08:48] <hrw> hi
[10:47] <egost> hi all
[10:47] <egost> i have troubles getting PowerVR SGX driver to work on blaze (omap4 ES1.0).
[10:47] <egost> can somebody confirm that?
[10:48] <egost> PVR_K: (FAIL) SGXInit: Incompatible HW core rev (10100) and SW core rev (10200).
[10:50] <egost> whole dmesg output : http://pastebin.com/raw.php?i=ZzhF7Lzy
[10:52] <egost> var/log/Xorg.0.log : http://pastebin.com/raw.php?i=w58UUAkU
[13:01] <bernard_> rsalveti: so, i couldn't reproduce the sd card corruption today, which is somewhat mysterious.
[13:01] <bernard_> i swear it happened repeatedly on monday, but maybe i was on something good.
[13:02] <bernard_> on an unrelated note, could this patch be incorporated into the ubuntu omap4 kernel?
[13:02] <bernard_> http://marc.info/?l=linux-omap&m=128744421925804&w=2
[13:02] <bernard_> it's upstreamed and in 2.6.37-rc1
[13:03]  * hrw wants it
[13:03] <ogra_ac> how would that affect systems where users set the MAC from u-boot already ?
[13:04] <hrw> anyway my dhcp server forces same ip for device which asks as panda
[13:04] <bernard_> in theory it shouldn't affect that at all.
[13:04] <bernard_> it just allows you to override it after boot.
[13:04] <bernard_> does the ubuntu omap4 kernel have a different patch for setting the mac address?
[13:04] <ogra_ac> nope
[13:05] <ogra_ac> file a bug and ask for SRU
[13:05] <ogra_ac> should be possible to pull it into maverick
[13:07] <bernard_> so it seems that the "linux" source package is collecting omap kernel bugs too. is that right?
[13:08] <ogra_ac> for omap3, yes
[13:08] <ogra_ac> and only in maverick
[13:08] <bernard_> what about omap4?
[13:08] <ogra_ac> for panda you want linux-ti-omap4
[13:09] <bernard_> ah, cheers.
[13:09] <bernard_> mind you, the beagle has the same ethernet chip.
[13:10] <ogra_ac> which is fine given we have two different kernel trees
[13:11] <ogra_ac> for natty omap3 will use upstream
[13:11] <bernard_> so should i file a bug on the linux package too?
[13:11] <ogra_ac> for maverick if you want to
[13:11] <bernard_> ah k
[13:11] <ogra_ac> natty will get it qutomatically
[13:11] <bernard_> where does the SRU tag go? subject? or is there a magic setting?
[13:12] <ogra_ac> https://wiki.ubuntu.com/StableReleaseUpdates
[13:26] <bernard_> wow. i couldn't even get two consecutive bug numbers within a couple of minutes. that's a disturbing bug rate :/
[13:26] <bernard_> but done. thanks!
[13:28] <ogra_ac> well, we have many users ;)
[13:30] <bernard_> many happy users too, i'm sure :)
[13:30] <ogra_ac> hopefully :)
[13:31]  * bernard_ loves having a native ARM build environment where apt-get just works.
[13:32] <rsalveti> bernard_: what happen when you set the mac address at the cmdline?
[13:32] <rsalveti> does it works as expected and never reset it again?
[13:33] <bernard_> rsalveti: cmdline as in kernel cmdline?
[13:33] <rsalveti> bernard_: yup, the current supported method
[13:35] <rsalveti> the patch seems fine, but it's something that you can already work with if you set it up at the kernel cmdline
[13:42] <bernard_> okay, to save me the 15 minutes to download the kernel source, what's the kernel parameter? :)
[13:43] <rsalveti> 1 sec, changing git branch :-)
[13:44] <rsalveti> macaddr=01:23:45:67:89:AB
[13:44] <rsalveti> for example
[13:45] <rsalveti> so, I agree it makes sense to apply your patch, but the reason would be more to avoid recreating the mac address on every ifdown/ifup
[13:45] <rsalveti> because we already have a way to stick with only one mac address
[13:45] <bernard_> cat /proc/cmdline
[13:45] <bernard_> vram=16M,omapfb.vram=0:5M,1:5M mem=460M@0x80000000 mem=256M@0xA0000000 root=/dev/sda1 fixrtc console=ttyO2,115200n8 rootwait macaddr=00:80:c8:40:8a:de
[13:45] <bernard_> but: % ip link list usb0
[13:45] <bernard_> 2: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ether 7a:ea:e9:22:5a:4b brd ff:ff:ff:ff:ff:ff
[13:47] <bernard_> uname -a: Linux cachehit 2.6.35-903-omap4 #14-Ubuntu SMP PREEMPT Wed Oct 6 17:23:24 UTC 2010 armv7l GNU/Linux
[13:47] <rsalveti> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commitdiff;h=10f38b455e75b85f72e98786e5518cf7b0324634;hp=f62e143182cc123fdfdf9bb88952a938af7d86e8
[13:47] <bernard_> rsalveti: another reason for using that patch is that it's what's in upstream, and consistent with other drivers. it also shouldn't break people who set it with current methods.
[13:48] <rsalveti> bernard_: sure
[13:48] <bernard_> ahh. i think it needs smsc95xx.macaddr then
[13:48] <rsalveti> sure, you're right
[13:49] <rsalveti> ok, will build a new kernel with your patch, and will put this comment at the bug
[13:49] <rsalveti> thanks for reporting it
[13:49] <bernard_> np. thank you!
[13:52] <bernard_> ack. the smsc95xx.macaddr= indeed works too.
[13:52] <rsalveti> cool
[14:05] <sebjan_> rsalveti, bernard_: just reconnecting to irc right now and see your chat:)
[14:05] <sebjan_> I have already commented on the launchad bug
[14:05] <rsalveti> sebjan_: after posting my comment I saw that you also commented on it :-)
[14:06] <bernard_> snap!
[14:06] <rsalveti> sebjan_: I'm now creating a new deb file to be tested
[14:07] <bernard_> there is also bug 673509 for omap3
[14:07] <ubot2> Launchpad bug 673509 in linux (Ubuntu) "Beagleboard-xm chooses a new IP address on each boot (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/673509
[14:07] <rsalveti> true, this would affect both
[14:08] <bernard_> (sorry to make you do more work! know that it's all greatly appreciated!)
[14:08] <rsalveti> one more to the pipeline
[14:08] <rsalveti> :-)
[14:08] <rsalveti> np at all
[14:23] <ogra_ac> NCommander, so i traced down the image build issues we have atm with cjwatson
[14:23] <ogra_ac> NCommander, seems we have a dpkg bug
[14:23] <ogra_ac> (telling you that because you wanted to work out why images fail)
[14:40]  * rsalveti lunch
[16:25] <rsalveti> ogra_ac: any chance to fix the current alsa-utils issue?
[16:25] <ogra_ac> rsalveti, not yet, i discussed several solutions and have to pick one
[16:25] <ogra_ac> generally we need a script that removes itself after first boot and calls the alsactl init
[16:26] <ogra_ac> s/boot/reboot/
[16:26] <ogra_ac> i'm just still pondering about the implementation details since all solutions are butt ugly
[16:26] <rsalveti> ogra_ac: but we still need to explicit call alsactl init?
[16:26] <ogra_ac> yes
[16:26] <ogra_ac> once
[16:26] <ogra_ac> and you need to call it after reboot
[16:27] <ogra_ac> since the kernel we get at the same upgrade needs to be running first
[16:27] <rsalveti> but the init is already calling when the  file /var/lib/alsa/asound.state is not there
[16:28] <rsalveti> but I didn't check if this file is created even with the wrong configuration
[16:28] <ogra_ac> that file is always there
[16:28] <ogra_ac> just not on brandnew installs
[16:28] <ogra_ac> it gets created on every shutdown
[16:29] <ogra_ac> so the code you look at is for new installs
[16:29] <ogra_ac> it doesnt help on upgrades
[16:29] <rsalveti> ok, it worked for me because at the first boot I just installed the new kernel and the patched alsa-utils that avoid calling alsactl init
[16:29] <rsalveti> then at the next boot everything was working fine
[16:29] <hrw> race condition
[16:29] <ogra_ac> no
[16:29] <hrw> what about systems like mine when upgrade of kernel != reboot?
[16:29] <ogra_ac> no race condition, expected behavior
[16:30] <ogra_ac> hrw, then a script has to be in place taking care for that
[16:30] <hrw> I sometimes do few kernel updates before reboot
[16:30] <ogra_ac> thats what i was talking about above
[16:30] <ogra_ac> thats fine
[16:30] <ogra_ac> the script will check for the right kernel running on boot
[16:31] <ogra_ac> if it sees the right one, it will call alsactl init
[16:31] <ogra_ac> and renove itself
[16:31] <ogra_ac> *move
[16:31] <rsalveti> don't know if removing itself is the best choice
[16:31] <rsalveti> maybe creating some kind of stamp somewhere
[16:31] <hrw> so situation is: kernel has proper alsa setup, but users have wrong one so we need to grab kernel one before alsa will use inproper one?
[16:31] <ogra_ac> rsalveti, that would mean you check for the stamp on every boot
[16:32] <rsalveti> ogra_ac: sure, something like what is already happening at [ -f /var/lib/alsa/asound.state ] || alsactl init
[16:32] <ogra_ac> rsalveti, right, we shouldnt add another one
[16:33] <rsalveti> just because I don't like stuff being removed from my system without any package removal
[16:33] <ogra_ac> better have a link somewhere that executes it and remove that link once it was run once
[16:33] <ogra_ac> as i said, its just about implementation details atm, i discussed all that at UDS with the audio guys
[16:33] <rsalveti> hrw: users need to update the kernel and then call alsactl init to initialize the correct config
[16:34] <rsalveti> so to make the sound work you need to reboot anyway
[16:34] <ogra_ac> right
[16:34] <ogra_ac> the kernel has the name changes to the alsa devices we require
[16:34] <ogra_ac> without the new names the alsa-utils changes cant work
[16:34] <ogra_ac> thats the catch22
[16:35] <hrw> no more "SDP4430 Media"?
[16:35] <ogra_ac> rsalveti, persia's suggestion was a here document from postinst, so it wont be handled by any package at all, neither the putting in place nor the removal
[16:35] <rsalveti> ogra_ac: sorry If I already asked this question, but why alsactl init is not called on every boot anymore?
[16:35] <ogra_ac> because thats resetting the mixers
[16:36] <hrw> rsalveti: what if you setup volume?
[16:36] <ogra_ac> hrw, no, no more SDP4430 Media
[16:36] <rsalveti> ok, the restore should be called, not init
[16:36] <hrw> omap4 mixer is not small beast
[16:37] <rsalveti> and restore also calls init when it fails
[16:37] <ogra_ac> rsalveti, right, thats the core bug
[16:37] <ogra_ac> restore should call init but it doesnt with our sound driver
[16:37] <ogra_ac> that will be investigated for natty
[16:37] <rsalveti> hm, ok
[16:38] <ogra_ac> hrw, SDP4430 is used in more boards and all of them require different mixer setups so we added names pre board for the device
[16:38] <ogra_ac> *per
[16:38] <ogra_ac> that way tha alsa init scripts can adjust them on a per board base
[16:39] <hrw> ogra_ac: I remember that discussions
[16:39] <GrueMaster> *Hopefully* UCM will handle this in the future.
[16:39] <rsalveti> hrw: http://paste.ubuntu.com/529441/ current result for panda
[16:40] <ogra_ac> GrueMaster, it will, you really should have been at plumbers
[16:40] <hrw> rsalveti: which ver of kernel?
[16:40] <rsalveti> previously was just SDP4430 - SDP4430 for all boards
[16:40] <GrueMaster> Yea, I figured as much.
[16:40]  * hrw needs to revert to natty on panda
[16:40] <rsalveti> hrw: 2.6.35-903-omap4 #17-Ubuntu
[16:40] <ogra_ac> revert ?
[16:40] <rsalveti> latest one available at maverick
[16:41] <hrw> ogra_ac: yes. today was linaro 10.11 testing day which is maverick. yesterday it was running natty
[16:41] <ogra_ac> ah
[16:41] <hrw> I do not have maverick on devices
[16:42]  * ogra_ac has only maverick on all systems here
[16:42] <hrw> but will reinstall smartbook to maverick to check kde4/armel status
[16:48]  * hrw reboots to #17 kernel
[16:51] <hrw> got panda
[16:53] <ogra_ac> now installinf alsa-utils should get you working sound
[16:54] <hrw> I did 'alsactl init' by hand
[16:54] <ogra_ac> that wont give you the right setup if you dont have the proper alsa-utils
[16:55] <hrw> ok
[16:59] <rsalveti> ogra_ac: who calls /sbin/alsa-utils start?
[16:59] <ogra_ac> rsalveti, udev iirc
[16:59] <rsalveti> hm, ok
[17:00] <ogra_ac> yeah, through an additionl script
[17:00] <ogra_ac> from /lib/udev/rules.d/80-alsa.rules
[17:00] <rsalveti> yup, saw it here now
[17:01] <ogra_ac> i have a skeleton for the postinst stuff, i'll finish that tomorrow during work hours
[17:01] <rsalveti> so it calls when it add controlC
[17:01] <ogra_ac> right
[17:01] <rsalveti> ogra_ac: sure, np, I'm just trying to understand now why restore is not following init
[17:01] <ogra_ac> i think its in alsactl itself
[17:02] <ogra_ac> look at the source there
[17:02] <rsalveti> yeah, doing that right now
[17:02] <ogra_ac> but generally init shouldnt be needed at all
[17:02] <ogra_ac> the driver should properly init and will hopefully do in natty
[17:03] <rsalveti> sure
[17:04] <ogra_ac> btw, what happened to the backtrace GrueMaster wanted to supply
[17:04] <rsalveti> don't know
[17:04] <ogra_ac> would be intresting to see the offending function
[17:04] <rsalveti> but it's probably something that the compiler optimized for neon
[17:04] <rsalveti> as neon is used for everything
[17:04] <ogra_ac> yeah
[17:04] <rsalveti> and not just neon capable files
[17:23] <aju> hi all,how create cross toolchain for ARM from scratch on ubuntu 10
[17:24] <hrw|gone> aju: "apt-get install arm-linux-gnueabi-gcc" is not enough?
[17:24] <hrw|gone> ;d
[17:26] <aju> hrw|gone, want to know complete process for creating toolchain on ubuntu 10
[17:27] <hrw|gone> aju: apt-get source armel-cross-toolchain-base + build it + install results + apt-get source gcc-4.5-armel-cross + build it + install it + apt-get source gcc-4.4-armel-cross + build it + install it
[17:27]  * hrw|gone out
[17:46] <RobotGuy> How do I replace the kernel in Ubuntu? I've built a 2.6.36 kernel and I want to install it.
[17:47] <RobotGuy> Ubuntu 10.10 built from an image.
[17:47] <aju> dpkg -i
[17:47] <aju> RobotGuy, using dpkg -i
[17:47] <aju> \pkg name
[17:47] <RobotGuy> I am talking building the kernel from sources, not installing from a binary.
[17:47] <ogra_ac> https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
[17:51] <RobotGuy> I think you are not understanding my question..  I have configured and built a 2.6.36 kernel from sources.  I want to install the new kernel and boot it.  How do I do that?
[17:51] <aju> RobotGuy, now you have .deb package of newly compiled binary?
[17:52] <aju> i mean for kernel 2.6.36 ?
[17:52] <RobotGuy> aju: NO I do not have a .deb package for the kernel.
[17:52] <ogra_ac> RobotGuy, you should build a deb
[17:52] <ogra_ac> if you know *ecxactly* wht your specific board needs for kernel and initrd treatment you can do that by hand indeed
[17:53] <ogra_ac> but i would refer to the board documentation for that
[17:53] <RobotGuy> As I said, I built a kernel from sources - 2.6.36   I want to install my new kernel and boot it.
[17:54] <aju> RobotGuy, yes either you can create .deb using make-kpkg and then use chroot and install it in target board or using ssh
[17:55] <RobotGuy> You are making this way over complicated.
[17:55] <ogra_ac> RobotGuy, then look at your board docs what your board needs exactly
[17:55] <ogra_ac> i.e. a u-boot booting board needs a uImage made from vmlinuz
[17:56] <RobotGuy> I have already built a kernel for my hardware.  Now I want to install it and boot it.  What is so difficult here?
[17:56] <ogra_ac> a redboot based board needs special treatment to dd the kernel into right place
[17:56] <rsalveti> RobotGuy: the ubuntu way would be to have a package for it
[17:56] <ogra_ac> that you didnt tell us anything about your hardware yet
[17:56] <rsalveti> if you already built your own kernel you can just give make deb-pkg
[17:56] <rsalveti> the upstream kernel also has a way to build a deb from the sources
[17:56] <rsalveti> and it works quite well with ubuntu too
[17:56] <RobotGuy> How is this going to help me install my new kernel?
[17:57] <ogra_ac> what hardware do you have there ?
[17:57] <RobotGuy> Hardware is a BeagleBoard-xM
[17:57] <rsalveti> it's easier because if you're installing it on a running board, the initrd will be generated when installing it
[17:57] <ogra_ac> so you need to run the right mkimage command
[17:57] <ogra_ac> and create a uImage
[17:57] <ogra_ac> then put it in the right place
[17:57] <RobotGuy> I already have a uImage
[17:57] <rsalveti> RobotGuy: if you just want to use a new uImage, just put it at the right place at the first partition
[17:57] <rsalveti> and make sure your modules are located at /lib/modules
[17:57] <ogra_ac> generate a corresponding uInitrd and put that in place as well
[17:58] <RobotGuy> rsalveti: That does not work.
[17:58] <ogra_ac> then your mkimage parameters were likely worng
[17:58] <ogra_ac> where/how does it stop ?
[17:58] <rsalveti> RobotGuy: it should work fine, if you put the modules in place and call depmod -a
[17:59] <ogra_ac> a deb cares for all that
[17:59] <RobotGuy> Is there a .deb package that matches a kernel 2.6.35.7-16, including config??
[17:59] <rsalveti> RobotGuy: having the deb file is easier, you just need to install it
[17:59] <rsalveti> and then making sure you're booting with the new uImage and uInitrd
[17:59] <RobotGuy> rsalveti: You do not understand.  I need sources to match the running kernel for development purposes.
[18:00] <ogra_ac> flash-kernel will care in this case
[18:00] <rsalveti> RobotGuy: so just use the new uImage, copy the modules to /lib/modules, update the modules cache with depmod and generate a new initrd
[18:00] <rsalveti> that should also work
[18:01] <RobotGuy> rsalveti: I have already tried that and it does not work.
[18:01] <aju> which emulator or IDE is available for ubuntu armel
[18:01] <ogra_ac> qemu
[18:01] <rsalveti> RobotGuy: it should work fine, probably something when wrong
[18:01] <aju> i mean i like test my app
[18:01] <ogra_ac> RobotGuy, well, if you dont give us any more info we cant help
[18:02] <aju> ogra_ac, for qemu need to boot complete os ?
[18:02] <ogra_ac> what does happen exactly or what doesnt ?
[18:02] <aju> or just application ?
[18:02] <ogra_ac> aju, both
[18:03] <RobotGuy> What more info do you need?
[18:03] <ogra_ac> you can install qemu-arm-static and run qemu-debootstrap --arch armel to cerate an arm chroot
[18:03] <ogra_ac> or you can use qemu-system, grab a versatile kernel and run a full VM
[18:03] <rsalveti> RobotGuy: did you give make modules_install INSTALL_MOD_PATH=/somewhere and then copied the modules to the correct directory?
 rsalveti: That does not work.
 then your mkimage parameters were likely worng
 where/how does it stop ?
[18:04] <RobotGuy> rsalveti: I know how to build kernels.  I've been doing it for years.
[18:05] <rsalveti> RobotGuy: so please post the exact error you're getting
[18:05] <RobotGuy> rsalveti: My problem does not have to do with building the kernel.  There is no error to post.
[18:06] <rsalveti> RobotGuy: you say it didn't work for you, but didn't say what went wrong
[18:07] <RobotGuy> First of all, I never said anything went wrong. Secondly, I came here asking how to do something, not how to correct an error.
[18:08] <rsalveti> RobotGuy: well, I gave you two working methods, and you said you don't want to use deb and the other one simply doesn't work for you, for some unknown reason
[18:09] <rsalveti> so I don't know how to help you more, unless you post us what went wrong with one of these options
[18:09] <RobotGuy> rsalveti: I told everyone what I need to do at the start.  Nobody has told me how to accomplish what I want to do.
[18:10] <rsalveti> RobotGuy: I told you 2 solutions, one is to build a deb and another is to produce a new uImage, install the modules by hand, generate the initrd and then reboot
[18:10] <rsalveti> as you asked how to replace ubuntu's kernel with your own sources
[18:13] <RobotGuy> I asked how to replace Ubuntu's kernel with my own kernel that I built from sources.
[18:14] <RobotGuy> This should not be rocket science.
[18:15] <rsalveti> and I gave you two working solutions for that
[18:15] <GrueMaster> RobotGuy: Let's start over.  Are you using our pre-installed image?  Is that the kernel you wish to replace?  Do you want to replace it before or after first boot?
[18:16] <RobotGuy> I started out from here ---> http://elinux.org/BeagleBoardUbuntu
[18:17]  * GrueMaster looks.
[18:18] <RobotGuy> I installed the Ubuntu image from there - 10.10
[18:18] <GrueMaster> Ok, that lists several images, both Ubuntu supported and some that someone created from ubuntu repos and posted as tarballs.  It also lists different versions (Maverick, lucid).
[18:18] <RobotGuy> I want to replace the kernel.
[18:18] <RobotGuy> maverick
[18:19] <GrueMaster> Please be more specific.  We have a pre-installed image that https://wiki.ubuntu.com/ARM/OMAPMaverickInstall points to, and there is a tarball on the link you posted as well.
[18:20] <GrueMaster> Two entirely different beasts.
[18:22] <GrueMaster> The "Demo Image" is not built or supported by Ubuntu other than at the package level.  The ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz that can be downloaded from http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/  is supported.
[18:22] <RobotGuy> All I want to do is have sources matched to the kernel my beagleboard is running.  I need this for development.
[18:23] <GrueMaster> Either way, we need to know exactly which one because they are completely different and require different approaches to replace the kernel.
[18:23] <RobotGuy> Which what??
[18:23] <GrueMaster> Which image.
[18:23] <RobotGuy> I already gave the info on where I got the image.
[18:24] <RobotGuy> http://elinux.org/BeagleBoardUbuntu
[18:24] <RobotGuy> Maverick 10.10
[18:24] <GrueMaster> I am looking at that link.  There is Maverick 10.10 preinstalled (linked through https://wiki.ubuntu.com/ARM/OMAPMaverickInstall), and below it is the Demo Image based on Maverick 10.10.
[18:25] <GrueMaster> So again, which image are you using?
[18:25] <RobotGuy> Demo Image, Maverick 10.10
[18:25] <GrueMaster> Ok.  Thank you.  Now we have a starting point.
[18:27] <GrueMaster> Unfortunately, I have know knowledge of that image at this time, but I think rsalveti's point of building a kernel deb package and installing that is the best bet.
[18:28] <RobotGuy> WHY do I want to build a kernel deb.  That is an unnecessary complication to what I need to do.
[18:28] <GrueMaster> If you already have a vmlinuz & initrd.img, then you can alternatively use mkimage to make a uImage and uInitrd to boot from.
[18:29] <aju> i have a basic question why uImage , u boot image x loader need to copy in Fat partition why not in ext ?
[18:29] <RobotGuy> I already have a uImage.  I need to create the matching uInitrd.
[18:29] <GrueMaster> If you scroll down the web link you posted, it has how to create a uInitrd from initrd.img.
[18:30] <RobotGuy> My basic question remains though: How do I get the sources that match the kernel that is installed with the image I am using??
[18:31] <GrueMaster> By installing the deb packages created when building the binaries.  Or copying the kernel source to /usr/src.
[18:31] <RobotGuy> The whole reason I went to build my own kernel is that I could not get sources to match the kernel on the image.
[18:31] <ogra_ac> RobotGuy, ask the person that created the image you used
[18:31] <ogra_ac> you are obviously not using an ubuntu image
[18:32] <RobotGuy> I'm using an image with ubuntu on it.
[18:32] <ogra_ac> right
[18:32] <ogra_ac> but not an image created by any ubuntu developer or in the ubuntu infrastructure
[18:32] <GrueMaster> As I said, we can support it at the *package* level (i.e. if there is an ubuntu package in it that is having issues).
[18:32] <ogra_ac> we can give you advise for ubuntu images
[18:33] <ogra_ac> or for ubuntu packages
[18:33] <RobotGuy> How do I know what images are or are not supported?
[18:33] <GrueMaster> If the images come from *.ubuntu.com.
[18:34] <ogra_ac> RobotGuy, GrueMaster just pointed you to some urls
[18:34] <GrueMaster> (or authorized mirrors).
[18:35] <GrueMaster> Our officially supported omap image for maverick is http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/release/ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img.gz
[18:36] <RobotGuy> Will that work on a BeagleBoard?
[18:36] <GrueMaster> Installation instructions are at https://wiki.ubuntu.com/ARM/OMAPMaverickInstall
[18:36] <GrueMaster> Yes.
[18:36] <GrueMaster> Tested on Beagle C4 & Beagle XM.
[18:36] <RobotGuy> OK, thanks.  I guess I need to switch images then.  I have a C3 and an xM.
[18:37] <GrueMaster> It should also work fine on the C3.  On the XM, be aware that there is a workaround for DVI on XM rev A3 or later.
[18:37] <RobotGuy> My xM is an A2
[18:37] <GrueMaster> Then it should just work.
[18:38] <aju> ogra_ac, i have a basic question why uImage , u boot image x loader need to copy in Fat partition why not in ext ?
[18:38] <GrueMaster> A3 moved the DVI enable line to a gpio after 10.10 release.  It has been fixed in a kernel update, but is tricky on first boot.
[18:38] <GrueMaster> But as you have A2, no worries.
[18:38] <RobotGuy> I'm glad. :D All this time I didn't know I was using an unsupported image of Ubuntu.
[18:38] <ogra_ac> aju, thats a u-boot limitation we had with the omap u-boot
[18:41] <GrueMaster> RobotGuy: No problem.  There are a lot of images and even full distributions based on Ubuntu (i.e. Mint) packages.  But we can only support the ones *we* create.
[18:42] <ogra_ac> and indeed, instead of switching images you can just talk to the creator of the image you use
[18:42] <ogra_ac> i.e. for a bug in mint you would talk to the mint devs
[18:44] <aju> ogra_ac, can uboot read kernel from ext3 ?
[18:44] <ogra_ac> ext2
[18:44] <aju> ok ext2 ?
[18:44] <ogra_ac> but not all revisions
[18:45] <RobotGuy> I don't know who created it apparently. I know you guys didn't make it now.
[18:45] <aju> because as convention it is required to copy uboot xloader and kernel in fat
[18:45] <RobotGuy> I'll just switch images.  That seems to be the easist path. :)
[18:45] <aju> will it work just copy uboot in fat and other in ext2?
[18:45] <aju> something i want to test and run differently
[18:46] <ogra_ac> you will have to rebuild u-boot with ext2 support
[18:46] <ogra_ac> it rpovided to be unstable when we tested it
[18:53] <RobotGuy> GrueMaster: I understand the whole support thing. ;D
[19:00] <RobotGuy> I just created an sd card with that image but it says it doesn't have a valid partition table.
[19:01] <RobotGuy> I forgot to gunzip it
[19:01] <ogra_ac> you shouldnt gunzip
[19:02] <ogra_ac> https://wiki.ubuntu.com/ARM/OMAPMaverickInstall has the proper instructions, use zcat
[19:25] <RobotGuy> That ubuntu supported image just freezed my beagleboard up on kernel boot.
[19:27] <GrueMaster> Do you see anything on the monitor?
[19:56] <RobotGuy> Yeah.  It appears there is a wait, reboot, wait cycle for this image to boot.
[19:58] <RobotGuy> Ahhh, x-image and I don't have keyboard/mouse connected yet.
[19:59] <GrueMaster> The first boot resizes the rootfs to fill the SD card.  The second one should boot into X with oem-config running so that you can setup keyboard locale, timezone, and user login info.
[19:59] <RobotGuy> It does.  My misunderstanding.
[19:59] <RobotGuy> I don't need X for the project I am working on though.
[20:01] <rsalveti> RobotGuy: you can boot with "text" at the cmd argument and you'll not get X
[20:02] <RobotGuy> I would prefer to not have X on the SDcard at all.
[20:03] <RobotGuy> I need dev stuff like gcc, etc.
[20:03] <RobotGuy> dev libraries.
[20:04] <RobotGuy> A console only dev image would be what I need/
[20:04] <GrueMaster> RobotGuy: The other thing you could do is build your own image with rootstock.
[20:05] <RobotGuy> I may have to do that.
[20:05] <rsalveti> yep, unfortunately we don't have a minimal image for maverick
[20:05] <rsalveti> rootstock is the way to go
[20:05] <rsalveti> at least for natty we'll have it
[20:05] <RobotGuy> That's too bad.
[20:07] <RobotGuy> We lose the serial console.
[20:08] <RobotGuy> At least if there were a minimal image, we could build up exactly what we need.
[20:09] <GrueMaster> One other (untested) solution is to download the netboot image and use it to install from the pool.
[20:09] <rcn-ee_at_work> RobotGuy, once you have my image it's easy to transition to ubuntu's kernel. ;)
[20:10] <RobotGuy> rcn-ee_at_work: What image is that?
[20:10] <rcn-ee_at_work> i was catching up on the irc log, 'my' image. ;)
[20:11] <RobotGuy> Would that be the one I am using now?
[20:11] <rcn-ee_at_work> Yeap it is.. from reading the backlog, you build a uImage and modules right? just dump the uImage in the fatfs and untar the modules to the rootfs.. the boot..
[20:12] <rcn-ee_at_work> after you build, there's a script under /boot/uboot/tools to rebuild the uInird, then reboot with all new..
[20:12] <RobotGuy> It can't find the linux partition
[20:12] <RobotGuy> Yeah, I know the script.  It doesn't do the right thing - uses the wrong kernel version.
[20:13] <rcn-ee_at_work> it uses the 'kernel' version from "uname -m or -r"
[20:13] <rcn-ee_at_work> so you need to boot with uImage for it to work..
[20:13] <RobotGuy> It always uses the version of the running kernel, which is wrong if I just created a new kernel.  It needs to use the version of the new kernel.
[20:13] <RobotGuy> I know that
[20:13] <rcn-ee_at_work> yeah, so copy the 'new' uImage to the boot, then reboot with the new uImage...
[20:14] <RobotGuy> You are not listening to me.
[20:14] <rcn-ee_at_work> as long as your modules are populate to /lib/modules/new_image/
[20:14] <RobotGuy> I know how to deal with kernels, but what you are saying does not work.
[20:14] <rcn-ee_at_work> Yeah i am.. So your running an old kernel.. You build a new one.. Take that new uImage and copy it to the fatfs dir.. then reboot your beagle, it'll run the new uImage..
[20:15] <RobotGuy> It does not find the rootfs partition.
[20:15] <RobotGuy> I don't know why.
[20:15] <rcn-ee_at_work> sounds like a config problem... can you pastebin your .config
[20:24] <rsalveti> ogra_ac: back to the alsa-utils issue
[20:24] <rsalveti> alsa-utils is calling alsactl restore with -I
[20:25] <rsalveti> -I,--no-init-fallback
[20:25] <rsalveti> it calls with no init fallback, gets the error, tries to sanify it and then calls restore again
[20:26] <RobotGuy> rcn-ee_at_work:   http://pastebin.com/87rjwxWm
[20:26] <rcn-ee_at_work> Thanks RobotGuy
[20:27] <RobotGuy> If it's the config, I don't know what the problem is.
[20:31] <rcn-ee_at_work> most of the obvious things are right, but "CONFIG_GPIO_TWL4030=m" should be builtin, i belive it sets the power to mmc card...
[20:31] <rcn-ee_at_work> diff'd mine and ubuntu's config we both got it as "=y"
[20:32] <RobotGuy> OK.  Would that cause it to not boot and not find things?
[20:32] <RobotGuy> Yes, I can see where that would make the mmc not available
[20:32] <rcn-ee_at_work> Well alot of the GPIO's on the TWL4030 control essential things like power control for the ehci/musb/mmc so if they don't get power...
[20:33] <RobotGuy> Would you fix and repost it for me please?  I just want it to work.
[20:34] <RobotGuy> I hate dealing with kernel configuration
[20:35] <rcn-ee_at_work> RobotGuy, i pushed it here: http://pastebin.com/uPS0w5dh  but if you have any more issues, my config for refernence is here: http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/annotate/head:/patches/lucid-defconfig
[20:36] <rsalveti> ogra_ac: just tested here, when booting with the old state file, at least for panda it'll be ok because the card name is different anyway
[20:36] <RobotGuy> Thankyou
[20:36] <rsalveti> and will store the correct values after first reboot
[20:36] <rsalveti> the problem will be just blaze, as the card name is the same as before the kernel patches
[20:37] <rsalveti> and restore with -F will try to restore most it can
[20:41] <rsalveti> ogra_ac: for panda the state file will be the same if you call alsa-utils start (with the initial wrong description for sdp4430) or call alsactl init
[20:42] <rsalveti> when giving restore the result is the same here, so don't know why you need to call alsactl init for panda at least one time
[20:43]  * rsalveti out for now, be back later
[21:06] <RobotGuy> rcn-ee_at_work: Now I get an internal compiler error. :(
[21:07] <rcn-ee_at_work> RobotGuy, ouch.. just by changing that one little config?  what file did it ice on?
[21:07] <rcn-ee_at_work> btw, which compiler? (the cross gcc from maverick's repo so far seems pretty sane..)
[21:21] <RobotGuy> mm/dmapool.c:351: internal compiler error: in try_ready, at haifa-sched.c:3222
[21:22] <RobotGuy> gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
[21:23] <RobotGuy> I am not cross building.
[21:25] <rcn-ee_at_work> RobotGuy, weird, on my last build with that version, it didn't have any issues with mm/dmapool.c (2.6.35.7)... http://rcn-ee.homeip.net:81/dl/farm/log/COMPLETE-2.6.35.8-l7_1.0-maverick.txt
[21:27] <RobotGuy> I'm building 2.6.36
[21:27] <rcn-ee_at_work> i know.. file hasn't really changed; http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.36.y.git;a=history;f=mm/dmapool.c;h=3df063706f53e6d579ec0acabace3503a471ba29;hb=HEAD
[21:28] <RobotGuy> All I want is the source to match the kernel I am running.
[21:28] <rcn-ee_at_work> what kernel are you running?
[21:29] <rcn-ee_at_work> (uname -a)
[21:29] <RobotGuy> 2.6.35.7-l6
[21:29] <RobotGuy> Linux tester 2.6.35.7-l6 #1 PREEMPT Wed Oct 20 01:32:27 UTC 2010 armv7l GNU/Linux
[21:30] <rcn-ee_at_work> 2.6.35 + 2.6.35.7 from kernel.org + http://rcn-ee.net/deb/maverick/v2.6.35.7-l6/patch-2.6.35.7-l6.diff.gz + http://rcn-ee.net/deb/maverick/v2.6.35.7-l6/defconfig
[21:32] <RobotGuy> OK, thanks. :)
[22:48] <NCommander> ogra: what's the dpkg bug number?