[00:00] <rcn-ee> i belive we are...  i'm not that high up, red river basin in north mn..
[00:01]  * GrueMaster is in Oregon
[00:03] <rsavoye> if we had an east coaster we'd cover all the US time zones at least :-)
[00:03] <GrueMaster> we do.  NCommander.
[00:15] <rcn-ee> rsavoye, give this one a try.. (it might not even boot, so back up your uImage) but it should detect more of the 'dm37xx' http://rcn-ee.homeip.net:81/testing/2.6.36/2.6.35-git8-dl0.uImage (modules are in the same directory if by some mircrale it works better..)
[00:17] <rsavoye> how to install ?
[00:18] <rcn-ee> you have a fat16/32 'uboot' partition on your sd card right? rename your uImage to uImage_bak... Copy this 'uImage' and rename it to 'uImage' if it boots just fine.. untar the modules .tar.gz as sudo right over top the rootfs, it'll create a /lib/modules/$(uname -r?)
[00:20] <rsavoye> yep. I'll try it after it downloads
[00:23]  * NCommander waves
[00:23] <NCommander> rsavoye: hey, how goes it?
[00:23] <rsavoye> stil trying to get my XM to run stably...
[00:29] <rsavoye> rcn-ee: you need to upgrade your net connection, an hour to download the uImage ? :-)
[00:30] <rsavoye> ah, now it's kicking in better....
[00:31] <rcn-ee> oh, it'll go eventually.... my farm is uploading *.deb images to rcn-ee.net too... it's 30Kb max upload, with my cable access.. sadly noting is better in this country area..
[00:32] <rsavoye> I know the problem,... I had to start my own rural ISP to get a connection at all...
[00:33] <rcn-ee> what's funny, digi-key is down the street, so they get 95% of the isp connection.. ;)
[00:34] <rsavoye> must be nice though if you need hardware :-)
[00:51] <rsavoye> does this new kernel run at 1Ghz ?
[00:53] <rcn-ee> i don't think it can yet.. 800mhz still..
[00:53] <rsavoye> better than 500Mhz... I've been building OpenJDK for 2 days now...
[00:54] <rcn-ee> some of the new 'base' pm stuff is in it..
[01:19] <rcn-ee> so rsavoye what's the story?  crash on boot? runs a little bit after boot? or eh it's still going? ;)
[01:25] <rsavoye> just ate dinner, let me try it
[01:47] <rsavoye> if I replace uImage with your image it doesn't boot.
[01:47] <rsavoye> I get funny characters to the serial port
[01:48] <rcn-ee> sweet, more things broken. ;)
[01:50] <rsavoye> more to fix that way :-) I'm around if you want me to try another one later
[01:50] <rsavoye> actually, what was the default baud rate ?
[01:50] <rsavoye> maybe I need to drop down from 115200
[01:53] <rcn-ee> oh 115200 been the default, just getting my testsetup up again..
[01:54] <rsavoye> that was the default for alpha2 and alpha3
[01:54] <rcn-ee> well it's been the default ever since i booted my first 2.6.21-ish on a beagle. ;)
[01:54] <rsavoye> I'm using multiple mmc cards now, so I can easily test later, and thrn go back to test builds on2.6.35-14-omap
[01:55] <rsavoye> sure beats the days of 9600baud only...
[01:55] <rsavoye> I'm compling Gnash a stress test, C++ code at -O3 is a great way to reproduce memory problems
[01:56] <rcn-ee> c++ apps are great for that. ;)
[01:56] <rsavoye> unfortunately...
[01:57] <rsavoye> funny enough when I build OpenJDL and Icedtea, the java code doesn't cause any problems, only C++ code
[02:01] <rcn-ee> well it's not a bad thing for stress testing. ;)
[02:02] <rsavoye> better us breaking it now than after the release. :-)
[02:04] <rsavoye> compiling away on 2.6.35-14-omap, before it never ran for more than 15minutes, so I'll let you know...
[02:04] <rcn-ee_lpt> hey ogra, from the irc log it looks my 'unique' /etc/flash-kernel.conf is messing some people up, is there a minimal amount of stuff i should put in there, before my 'to use ubuntus kernel remove the next command' 'exit 0'?
[02:05] <GrueMaster> He's in Germany.  3am.  If he answers, I would be very surprised.
[02:06] <GrueMaster> What does your flash-kernel.conf look like?
[02:06] <rcn-ee_lpt> yeap, i was hoping he was doing some midnight coding.. ;)
[02:07] <rsavoye> I think we're the only ones awake
[02:07] <rcn-ee_lpt> the one /etc/flash-kernel.conf i'm adding to my images was for the lucid days, but it sounds liek maverick needs more stuff:  http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/image-builder/annotate/head:/tools/fixup.sh
[02:08] <rcn-ee_lpt> the DONT_FLASH part was a patch i was working on but dropped..
[02:09] <GrueMaster> Lucid wrote the kernel to nand, Maverick uses a 70M fat32 partition.  It needs to have UBOOT_PART=<vfat partid> in it.
[02:10] <GrueMaster> especially for XM and systems w/o nand.
[02:11] <rcn-ee_lpt> eh, that's what i'm missing, thanks GrueMaster i'll add it to the next upload, and tweak the message to make it easier for users trying to switch between. ;)
[02:11] <rcn-ee_lpt> actually i originally wrote it for my xm with lucid, after which i found out the netinstall would just crash with lack of nand on my xm. ;)
[02:12] <GrueMaster> Something like this?  http://paste.ubuntu.com/475699/
[02:13] <rcn-ee_lpt> i'd personaly remove all nand stuff.. ;) to many rma's and confused customers.. ;)
[02:13] <GrueMaster> Makes sense.
[02:13] <rcn-ee_lpt> almost number one reason the xm doesn't have nand..
[02:14] <rcn-ee_lpt> on the other hand it's a nice clean install for a single distrubution.. ;)
[02:14] <GrueMaster> Interesting how we went from having to show people how to program their VCR to having to show people how to program their embedded development system.
[02:15] <rcn-ee_lpt> you didn't use electrical tape? ;)
[02:15] <GrueMaster> For my VCR?  Had a roll on an office tape dispenser next to it.
[02:16] <rcn-ee_lpt> but yeah, over the last year, my wiki has gone from.. follow these examples exactly too run this script...
[02:16] <rsavoye> less tech support that way
[02:18] <GrueMaster> Now if TI (or one of their oems) were to make something like this...http://en.qi-hardware.com/wiki/Ben_NanoNote
[02:21] <rcn-ee_lpt> that would be neat to have.. i'm been looking at this.. omap3530 powered http://www.slashgear.com/nationite-midnite-android-2-2-mid-an-affordable-cortex-a8-tablet-0696771/
[02:21] <rsavoye> so far so good, one directory compiled without segfaults
[02:21] <rcn-ee_lpt> is that with 2.6.35-14-omap?
[02:21] <rsavoye> yeah
[02:22] <rsavoye> from the linaro image
[02:22] <rsavoye> how can I see what clock speed it's running at out of curiousity ?
[02:22] <rcn-ee_lpt> cat /proc/cpuinfo...
[02:23] <rsavoye> ah, 500Mhz. oh well... :-)
[02:23] <rsavoye> still, sharing a beagle board in NZ is kindof slow...
[02:24] <rcn-ee_lpt> well.. by default u-boot set's it up for 500, passes mpurate to the kernel, (which i don't think ubuntu
[02:24] <rcn-ee_lpt> 's boot.scr uses yet...
[02:25] <rsavoye> if it's stable, I'll be glad to have that than a higher clock rate
[02:25] <rcn-ee_lpt> yeap, right now stable on an xm is better then anytyhing..
[02:26] <prpplague> rcn-ee_lpt: could be on a beagle mounted on a mars rover
[02:26] <prpplague> rcn-ee_lpt: i'm thinking the ping times would be pretty large
[02:27] <rcn-ee_lpt> that would be cool prpplague you'd have to script everything no point in waiting for commands..
[02:27] <rsavoye> the spec for the Delay Tolerant Network is pretty cool
[02:28] <rsavoye> it's the exact opposite of real time...
[02:34] <GrueMaster> Just be thankful this hasn't become a standard yet.  http://www.faqs.org/rfcs/rfc2549.html
[02:35] <GrueMaster> Although if MS ever hears about it...
[02:36] <rcn-ee_lpt> well, they'd just implement it after bsd. .;)
[02:37] <prpplague> GrueMaster: i thought they already implemented it in wince, that's why it runs so slow
[02:37] <GrueMaster> Heh.
[02:57] <rcn-ee_lpt> rsavoye, it's funny.. that uImage booted for me.. (well dss2 is broken so no screen)
[02:57] <rsavoye> should I do anything after copying the uImage ?
[02:58] <rcn-ee_lpt> nope, just the uImage... lets see if it survies my aptitude test..
[02:59] <rcn-ee_lpt> nope, crash.. can't wait for a production unit. ;)
[03:01] <rsavoye> aaarrrggg, same ol segfault. oh well...
[03:02] <rcn-ee_lpt> i get this... dss2 is broke.. http://pastebin.com/1UpFddvN
[03:04] <rsavoye> I get http://paste.ubuntu.com/475715/
[03:04] <rsavoye> it segfaults still, but differently than when I ran your other kernel a few days ago
[03:05] <rcn-ee_lpt> yeap, we are still missing the usart3.. (basicly the omap3630 core added another usart ove rthe omap35xx) it hasn't been implemented yet..
[03:06] <rsavoye> guess this will make me eager to test new kernels, hoping one works :-)
[07:58] <lag> rcn-ee: Are you here/
[07:59] <lag> cooloney: Morning
[08:12] <cooloney> lag: morning, man
[08:12] <cooloney> you are very early
[08:13] <lag> I'm always here 0700-30
[08:13] <lag> cooloney: bug 612895
[08:13] <ubot2> Launchpad bug 612895 in linux-ti-omap4 (Ubuntu) "Unable to handle kernel NULL pointer dereference at virtual address 00000000 (affects: 1) (heat: 1674)" [Undecided,Confirmed] https://launchpad.net/bugs/612895
[08:13] <lag> And the kernel you asked me to test
[08:13] <lag> Where did you get the _fix_?
[08:14] <cooloney> lag: i saw you are trying 902 kernel. and we just upgraded to latest TI release
[08:14] <cooloney> lag: maybe you can try that
[08:15] <cooloney> lag: the latest TI release fixed one swap oops
[08:15] <cooloney> ndec: morning
[08:16] <ndec> cooloney: morning.
[08:20] <lag> ndec: Morning :)
[08:20] <lag> cooloney: When did you update?
[08:20] <ndec> lag: morning!
[08:21] <cooloney> lag: tim pull it last week. it is 2.6.34 based release
[08:21] <cooloney> not 2.6.35
[08:23] <hrw> morning
[08:39] <zumbi> hrw: hi
[08:40] <zumbi> hrw: where do you keep your compilers packaging
[08:45] <hrw> zumbi: 2 places
[08:45] <hrw> 1. http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/
[08:45] <hrw> 2. https://edge.launchpad.net/~hrw/+archive/arm-cross-compiler
[08:46] <hrw> 1st has cross compiler packages
[08:46] <hrw> 2nd has my work on binutils/eglibc/gcc and related packages
[08:46] <zumbi> hrw: should we try to sync on getting this into Debian together?
[08:47] <zumbi> (or you might not care on Debian?)
[08:48] <hrw> zumbi: all my work is first in Debian ;d
[08:48] <zumbi> while most of the work is fine, I have some suggestions on the packaging
[08:48] <hrw> zumbi: zless /usr/share/doc/gcc-4.4/changelog.Debian.gz please
[08:49] <hrw> zumbi: I am listening
[08:49] <zumbi> hrw: yes, i saw that changelog, but i do not see it on linux, nor eglibc
[08:49] <hrw> linux in Debian is other recipe then in Ubuntu...
[08:50] <hrw> zumbi: I need: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=b4f64f3350b628323e39f69b416523f60c7f11f2 http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=b4c776c2bc2c183fe13d3ed5f23e00fd9cb62a1d in kernel source package
[08:50] <zumbi> hrw: while one package for cross compiler (armel-cross-toolchain) could be fine. I would suggest to do some package split for building reuse
[08:51] <zumbi> hrw: I have some dependency graph which might clarify package dependencies a little
[08:51] <hrw> ok
[08:53] <zumbi> hrw: I need some time to build an image of the dependency graph (source at: http://emdebian.org/git/?p=talks/emdebian.git;a=blob;f=pkgdeps.dot;h=9380b2fb14c6ffb6ecb66c05bc71cb375098531f;hb=HEAD )
[08:53] <zumbi> hrw: I'll ping you back once i get a better looking file
[08:54] <hrw> ok
[08:55] <hrw> what you use to visualize it?
[08:56] <lool> dotty
[08:56] <zumbi> dot -Tdot pkgdeps.dot | gvpr -c '' | dot -Tpdf -o pkgdeps.pdf
[08:57] <zumbi> brb
[08:57] <hrw> thx
[08:57] <lool> hrw: So you're essentially building a package which takes as input *-source, and outputs all the cross-toolchain .debs; I think zumbi is looking for some modularity, such as building binutils separately, or not rebuilding all stages; I don't think all the modularity is easy, so let's shoot at completing a cross toolchain first, and then we will make it more modular
[08:58] <lool> My understanding of zumbi's main concern is the time it would take to build the whole bootstraped toolchain
[08:58] <lool> I personally think this is ok, but I understand why he would like to skip some stages / packages in Debian
[08:58] <hrw> 56 minutes on my core2quad
[08:59] <lool> sweet
[08:59] <hrw> zumbi: your graph has a bug. 1st stage of gcc do not need eglibc
[08:59] <hrw> zumbi: and do not need linux headers - thats what eglibc wants
[09:04] <zumbi> back
[09:05] <zumbi> hrw: the most important think i wanted to show you from the graph is capability to rebuild non default compilers
[09:06] <zumbi> hrw: so if default is 4.4, you could reuse all libs to rebuild 4.3, 4.5, ..
[09:06] <hrw> zumbi: take my armel-cross-toolchain source package, change component inside, build
[09:06] <hrw> version of gcc inside is set by VER_GCC variable
[09:06] <hrw> 4.4 and 4.5 should work
[09:06] <zumbi> hrw: ok - i'll do
[09:06] <hrw> 4.3 is not present in ubuntu so I did not changed it
[09:07] <hrw> if you want to use <4.4 then you will need to merge changes from 4.4
[09:07] <hrw> and there are still lot of changes which I need to merge
[09:07] <zumbi> hrw: but you no need to rebuild everything for both compilers (that was my suggestion) :)
[09:10] <hrw> phone...
[09:11] <lool> zumbi: Yes, in general, the structure of cross-compiler packages is not perfectly defined
[09:11] <lool> zumbi: for instance, which package should provide $triplet-gcc?
[09:12] <lool> zumbi: My take on this is that there are two types of users: a) people who want to quickly build a standalone cross-toolchain
[09:12] <lool> and b) people who want to build cross compiler packages which match as much as possible the native toolchain
[09:13] <lool> for the later case, I think we need to output -gcc-4.5, -gcc-4.4 and -gcc files, and that should be the default; for the former I think we should add a flag to the gcc cross-build to allow building a standalone package
[09:13] <zumbi> lool: and c) people wanting to just intall the binaries :)
[09:13] <lool> zumbi: I'm not sure what you mean
[09:14] <lool> I think the in-archive packages should be of type b), but they will be of type a) in the beginning
[09:14] <zumbi> lool: right
[09:15] <zumbi> lool: sounds fine
[09:19] <hrw> I think that we try to make a) == b)
[09:19] <hrw> at least thats my goal with ubuntu packages
[09:20] <lool> hrw: Hmm, I'm not sure it's possible
[09:20] <lool> hrw: Consider that gcc comes from gcc-defaults right now
[09:20] <lool> hrw: And that people might want to build a standalone cross-toolchain which ships $triplet-gcc, even if it's not the gcc-4.x they build from is not the default
[09:23] <hrw> my wife is refuelling our car for first time so I am remote helpdesk
[09:24] <hrw> lool: current ubuntu cross gcc packages (4.4 4.5) ships $triplet-gcc-VER + u-a stuff to make it $triplet-gcc (gcc/cpp/gcov/g++ etc)
[10:00] <lool> hrw: yeah, alternatives suck though    :-/   but it's good to have that in place at least
[10:01] <hrw> speaking of cross-gcc-defaults package... I looked at gcc-defaults one and I think that will make new one based on it instead of adding cross support to this one.
[10:12] <hrw> armel-cross-toolchain 1.7 builds now. will fail anyway
[10:22] <hrw> 1.8 on a way
[12:44] <rcn-ee> lag pong
[12:45] <lag> Hi Robert
[12:46] <lag> Your patch for ro
[12:46] <rcn-ee> how's it going lee..
[12:46] <lag> Are you going to push it upstream?
[12:46] <lag> Good thanks :)
[12:47] <rcn-ee> for the xm, when the hardware is released, i'll send it to linux-omap, it'll probally get tweaked..
[12:50] <lag> rcn-ee: Why don't you throw it up there now?
[12:52] <rcn-ee> i don't really have a good excuse. ;)
[12:54] <lag> The boards don't work without it
[12:54] <lag> Is that good enough? ;)
[12:56] <rcn-ee> i'll run it thru the patch checker script, and sent it to linux-omap, one more thing enabled for the xm..
[12:58] <ogra> \o/
[12:59]  * ogra sighs about oem-config
[13:00] <ogra> i also just stopwatched the resizing ... 2:30 for two boots and the whole resizing process on a 4G card
[13:00] <ogra> (each boot takes 35sec for u-boot until the kernel comes up)
[13:00] <ogra> amitk, do you still think thats to slow ? :)
[13:01] <hrw> 2h30m?
[13:01] <ogra> 2min 30sec :)
[13:01] <ogra> of which 1min 1sec are simply u-boot stuff
[13:01] <ogra> err
[13:01] <ogra> 10sec
[13:02] <hrw> ogra: and how much from first start to final desktop?
[13:02] <ogra> hrw, no idea, thats from pushing in the power plug to oem-config
[13:02] <rcn-ee> 35 seconds for u-boot? you could cut the u-boot wait variable.. ;)
[13:03] <hrw> oem-config etc took ages last time
[13:03] <ogra> answering the oem-config questions will likely take another 2-3min (depending how fast you type and click) plus package removal time which i couldnt stopwatch yet
[13:03] <amitk> ogra: no, it is loooking _much_ better. Congratulations :)
[13:03] <ogra> note that i'm talking about omap4 here
[13:04] <ogra> i dont test on the C4 anymore and XM is currently broken kernel wise
[13:04] <hrw> on Cx you have to multiply by 10
[13:05] <rcn-ee> still pretty quick, is your u-boot for the omap4 like the omap3, where it has a 10 second wait at boot?
[13:05] <amitk> ogra: I know you cheated :-p But it is still a lot better than the 1.5hr installs
[13:05] <ogra> hrw, well, if we get the XM working i wont recommend the images for Cx installations
[13:05] <hrw> ogra: so far I am stick with C3s anyway
[13:05] <ogra> its simply not up to par with the minimal requirements
[13:06] <hrw> btw - how often does ubuntu devs reboot their 'desktops'?
[13:06] <rcn-ee> sweet, looks like a real patch for 588243 just it linux-omap..
[13:06] <ogra> after update-manager forced me to
[13:07] <hrw> ogra: I am ~5 kernels behind current
[13:07] <amitk> bad hrw
[13:07] <ogra> yeah
[13:07] <ogra> you should listen to your update-manager :)
[13:07] <hrw> ogra: aptitude do not said anything ;D
[13:07] <ogra> shudder
[13:07] <ogra> dont use aptitude
[13:08] <amitk> hrw: aptitude is not recommended by our update guys
[13:08] <hrw> so what :D
[13:08] <amitk> it resolves dependencies in a different (unsupported) way
[13:08] <hrw> I cant stand other apt utils then aptitude and apt-get
[13:08] <ogra> hrw, do-release-upgrade is what you want if you are a cmdline guy
[13:08] <hrw> if it require me to use mouse then it is not good
[13:09] <hrw> 13:56 hrw@home:debian$ sudo do-release-upgrade
[13:09] <hrw> [sudo] password for hrw:
[13:09] <hrw> Checking for a new ubuntu release
[13:09] <hrw> No new release found
[13:09] <ogra> its the equivalent to update-manager
[13:09] <ogra> what are you running ? lucid or maverick ?
[13:09] <hrw> maverick since uds
[13:10] <ogra> ah, that might be different
[13:10]  * ogra doesnt run maverick on his main machine
[13:10] <amitk> what's wrong with 'sudo apt-get update; sudo apt-get dist-upgrade -V'
[13:10] <ogra> nothing
[13:10] <hrw> amitk: aptitude logs what I isntalled etc
[13:10] <ogra> hrw, apt too
[13:11] <hrw> ogra: it did not when I started using aptitude
[13:11] <amitk> hrw: /var/log/apt/
[13:11] <hrw> aptitude also shows what new, what local/obsolete etc
[13:11] <ogra> apt-get autoremove :P
[13:12] <hrw> I used console-apt and few other ncurses/slang frontends in past
[13:12] <ogra> ah, you need a gui ?
[13:12] <ogra> well
[13:12] <hrw> ogra: that does not tell that libdvdcss2 is from outside of ubuntu
[13:13] <hrw> or that binutils-arm-linux-gnueabi is also not ubuntu package
[13:14] <ogra> why didnt you use the one inside of ubuntu ?
[13:14] <ogra> (for DVD playback, use libdvdread4 and run /usr/share/doc/libdvdread4/install-css.sh )
[13:15] <hrw> do not remember now
[13:15] <hrw> ogra: that script does same as I did - fetch pacakge and install
[13:16] <ogra> yeah
[13:16] <ogra> likely
[13:16] <hrw> but I play one dvd per year so...
[13:17]  * amitk doesn't even have a laptop with dvd drive any more
[13:17] <hrw> did I said laptop?
[13:17] <ogra> mine annoyingly has one
[13:17] <hrw> I never owned laptop with drive
[13:17] <ogra> (with an eject button you always hit if you lift it)
[13:18] <hrw> ogra: remove it from case?
[13:18] <ogra> then i have an open hole in my lappie
[13:18] <ogra> the drive is customized to the case
[13:19] <ogra> and i have no placeholder or something to put into the empty slot
[13:19] <hrw> so nothing other can fit?
[13:19] <ogra> i guess when the laptop was recent you could buy dummies to put into the slotr
[13:20] <ogra> but thats 2.5 years ago and the model isnt produced anymore
[13:25] <lag> rcn-ee: Sounds good (I saw that your tabs are out, besides that it looked okay)
[13:28] <rcn-ee> yeah, noticed that when i added the patch to the lp bug.. (crap wrong tabs..) btw, i think this fixes lp bug 588243 http://www.spinics.net/lists/linux-omap/msg34582.html going to test it this morning..
[13:28] <ubot2> Launchpad bug 588243 in linux-ti-omap (Ubuntu) (and 1 other project) "kernel BUG at /build/buildd/linux-ti-omap-2.6.33/drivers/video/omap2/dss/core.c:323! (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/588243
[13:37] <lag> rcn-ee: That's a lot of extra code
[13:37] <lag> :)
[13:37] <lag> I'm sure cooloney will be glad to hear of it
[13:39] <lag> rcn-ee: I'm commented on the bug with your information
[13:54] <lool> ogra: Around?
[13:54] <lool> ogra: Do you remember that discussion about changing the image generatin to output fat32 specifically?
[13:58] <ogra> lool, yes, i changed it for you back then, does it work now ?
[13:58] <lool> No
[13:58] <lool> That's why I'm around
[13:58] <ogra> iirc we still have a bug open thats pending confirmation
[13:58] <lool> One thing I noticed, and I had mentioned on IRC, is that the number of heads is non-default when I regenerate it here
[13:59] <ogra> "regenerate" ?
[13:59] <lool> ogra: If you sudo losetup -fv maverick-preinstalled-netbook-armel+omap.img, then sudo kpartx -av /dev/loop0, then compare: sudo fdisk -l /dev/loop0
[13:59] <lool> and sudo file -s /dev/mapper/loop0p1
[13:59] <lool> you'll see that they don't have the same number of heads
[14:00] <lool> yep, confirmed, that fixed it for me
[14:00] <ogra> the CHS geometry is indeed adjusted to the image size, i havent seen any issues with dd'ed images
[14:01] <lool> ogra: So if you check the number of heads in the FS, it says 64; if I regenerate the fs, copying back the same files in, it generates a FS with 255 heads here, and it boots in QEMU
[14:02] <lool> (now it doesn't work because I get no keyboard and no /dev/mmcblk0p2, but still it will boot into the initramfs!)
[14:02] <ogra> {
[14:02] <ogra>     echo ,9,0x0C,*
[14:02] <ogra>     echo ,,,-
[14:02] <ogra> } | sfdisk -D -H 255 -S 63 -C $CYLINDERS $IMAGE >/dev/null 2>&1
[14:02] <ogra> thats the code from the debian-cd script (which originally comes from angstrom)
[14:02] <lool> this isn't the problem
[14:03] <ogra> but that defines the sectors
[14:03] <lool> I'm speaking of the heads in the *filesystem*
[14:03] <ogra> err, heads indeed
[14:04] <ogra> mkdosfs -F 32 -C $IMAGE.vfat ${VATSIZE} >/dev/null 2>&1
[14:04] <ogra> thats the filesystem creation, with -F32 added as you requested
[14:04] <ogra> could it be that our mkdosfs on antimony is to outdated ?
[14:05] <lool> Maybe, but looking at the code, I rather think that it's because I'm running it on a different device that I get different results
[14:05] <lool> Current images: /dev/mapper/loop0p1: x86 boot sector, mkdosfs boot message display, code offset 0x58, OEM-ID " mkdosfs", Media descriptor 0xf8, heads 64, sectors 144522 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 1112, serial number 0x4c5f659b, label: "           "
[14:05] <ogra> that might be, i get proper partition tables and filesystems if i use it from SD card
[14:06] <lool> after mkdosfs on a loop device:
[14:06] <lool> /dev/mapper/loop0p1: x86 boot sector, mkdosfs boot message display, code offset 0x58, OEM-ID " mkdosfs", Media descriptor 0xf8, heads 255, sectors 144522 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 1112, serial number 0xcafca2f1, label: "           "
[14:06] <ogra> weird
[14:08] <lool> >-------printf ("unable to get drive geometry, using default 255/63\n"); bs.secs_track = CT_LE_W(63); bs.heads = CT_LE_W(255);
[14:10] <lool> interestingly, it tries to default to 64 heads on loop devices, but fails to detect my device as a loop device
[14:10] <ogra> kernel issue ?
[14:11] <lool> ogra: Well it's just that it checks for loop major device (7), but I'm using a mapper device (major 252)
[14:12] <ogra> ah
[14:12] <ogra> but could that in any way affect your qemu boots ?
[14:12] <lool> 252 actually means "local/experimental use"
[14:12] <ogra> i doubt it
[14:12] <lool> qemu apparently reads the number of heads from the FS
[14:13] <lool> and refuses to boot with heads == 64
[14:13] <ogra> hmm
[14:13] <lool> I need to say that the partition table actually says 255, so QEMU has a point in not booting   :-)
[14:13] <ogra> but the 255 is needed for real HW :)
[14:14] <lool> the 255 is fine
[14:14] <lool> the bogus part is the 64 heads in the FS
[14:14] <ogra> 255/63 is a requirement, else x-loader wont work
[14:14] <lool> Err which 63 is that?
[14:15] <ogra> sectors
[14:15] <lool> I'm only speaking of heads here
[14:15] <ogra> the DOS standards
[14:15] <lool> sectors don't matter really
[14:15] <lool> (here)
[14:18] <ogra> not here but for the actual images, the partitioning needs to be that way, i dont know how i would change the amount of heads the filesystem uses though, seems mkdosfs has no option for that
[14:18] <lool> so it's a set of mkdosfs bugs, but not fun to fix
[14:19] <lool> ogra: it's because mkdosfs has a different code path for files and for devices
[14:20] <lool> for files, it checks the size and defaults to 32 sectors and 64 heads
[14:21] <lool> for unknown devices, it assumes hard disk and checks the geometry, but fails and so uses 63 sectors per track and 255 heads
[14:22] <ogra> meh
[14:23] <ogra> lool, i'm planning to provide a script that loop mounts and reformats the vfat for bootloader changes on existing images, we could have some workaround in there that makes it work for you too
[14:24] <ogra> (we want to provide the same image for blaze and panda but that requires different x-loader and u-boot)
[14:25] <lool> ogra: i'd rather fix mkdosfs
[14:25] <ogra> lool, in hardy ?
[14:25] <ogra> dont forget antimony is hardy
[14:29] <lool> ogra: Well we can certainly prepare a special fixed package to install there
[14:29] <ogra> indeed
[16:03] <lag> ogra: If I want to test my bespoke kernels with the daily image - what's the easiest way?
[16:16] <lool> ogra: Hmm it's more complex than I thought
[16:16] <lool> LP #615873
[16:16] <ubot2> Launchpad bug 615873 in dosfstools (Ubuntu) "Doesn't allow forcing file systems to 255 heads (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/615873
[16:31] <hrw> someone remember how to tell "dch" to not use "ubuntu1" but bump version?
[16:32] <lool> hrw: Bump to what?
[16:32] <lool> hrw: You can -i to force a version increment, or -a to force not touching the version; you can -v to set the version
[16:33] <GrueMaster> lag: what platform do you want to test on?
[16:33] <lag> Arm
[16:33] <GrueMaster> Duh.
[16:33] <GrueMaster> Little more specific.
[16:33] <lag> OMAP3+4
[16:34] <GrueMaster> If you want to test on Beagle & Panda, probably easiest to use the Alpha 3 image and install kernel after the image expands and oem-config runs.
[16:35] <GrueMaster> If you want to test on XM, boot an image on beagle first, then install new kernel.
[16:35] <GrueMaster> Not sure if you can just put the uImage on the image w/o updating uInitrd.
[16:35] <lag> Hmm
[16:35] <lag> You can't
[16:35] <lag> depmod not found
[16:36] <lag> So, let them come up and install kernel.deb after?
[16:36] <GrueMaster> That would be easiest.
[16:36] <rsavoye> alpha3 has problems still on my XM
[16:37] <GrueMaster> yes, I know.
[16:37] <GrueMaster> The other possible way is to generate an image with rootstock, but I don't know how well that works.
[16:37] <hrw> lool: yes, but -i bumps from 1.10 to 1.10ubuntu1 when I want 1.11
[16:38] <rsalveti> yep, with rootstock you can give the kernel image to be used while creating the rootfs
[16:39] <lag> rsalveti: But I want to test it with the daily build
[16:40] <lag> rsalveti: i.e. the daily build's rootfs
[16:40] <rsalveti> GrueMaster: lag: another way is to copy qemu-arm-static to <sd-card>/usr/bin and run chroot
[16:40] <rsalveti> after that you're able to install normally
[16:40] <lool> hrw: --distributor Debian?
[16:41] <rsalveti> lag: well, the advantage of using rootstock is that you can test another kernel easily, without having to wait the daily rootfs to be created
[16:41] <hrw> lool: ok, thx
[16:41] <lag> rsalveti: I have kernels that I know work with rootfs, but they don't when they're used with the daily build
[16:42] <lag> rsalveti: I need to test them with the daily build's rootfs
[16:47] <rsalveti> lag: so, installing the new kernel deb with chroot is how I'd recommend you to do it
[16:47] <rsalveti> if you don't have access to the machine running your rootfs
[16:47] <rsalveti> but then you need to create and copy uI* files
[16:49] <lag> Does the daily build's rootfs have update-initramfs?
[16:49] <lag> And mkimage?
[16:49] <rsalveti> GrueMaster can easily check
[16:55] <GrueMaster> yes, they do.  Sorry, had to step out for a bit.
[16:56] <ogra> lag, create a package, dpkg -i it
[16:57] <ogra> lool, well, my offer still stands, i can add a special mode to the script
[16:57] <lag> But that's saying I have a running system
[16:57] <lag> ogra: XM is borked
[16:58] <ogra> lag, yeah
[16:58] <lag> How how can I dpkg -i on the XM?
[16:58] <ogra> lag, another way is to dpkg -i your package in a chroot and just use mkimage on the files
[16:58] <ogra> and then replace them on the SD
[16:58] <lag> Yeah, that's whay rsalveti said
[16:59] <lool> ogra: It looks like we're creating a broken vfat
[16:59] <lool> I'm worried about mtools_skip_check=1
[16:59] <ogra> thats what i do for jasper development
[17:00] <ogra> lool, iirc we a) use that elsewhere too in debian-cd, b) as long as the bootloader likes it i'm fine, we repartition and recreate the vfat on first boot anyway
[17:01] <ogra> lool, seems the only thing that doesnt cope with our images is qemu here
[17:05] <lag> ogra: Can I just update-initramfs <kernel-image> in a chroot and use the uInitrd and uImage files?
[17:05] <ogra> lag, you need the mkimage calls too
[17:05] <ogra> but yes
[17:05] <lag> What do I need to do with the rootfs?
[17:05] <ogra> nothing
[17:05] <lag> Just copy the modules into /lib/modules?
[17:06] <rsalveti> lag: yep
[17:06] <ogra> just dpkg -i your package or create the modules dior manually
[17:06] <rsalveti> lag: the packages just installs the modules
[17:06] <rsalveti> then depending on your changes you need to generate the initrd.img again
[17:06] <rsalveti> then create the uI* files and rock on
[17:07] <lag> Why do I need to make them twice?
[17:07] <lag> Compile kernel
[17:07] <lag> Make uImage
[17:07] <lag> Make uInitrd.img
[17:07] <lag> Make uInitrd
[17:07] <lag> Copy to rootfs
[17:08] <lag> Copy modules to /lib/modules
[17:08] <lag> Done
[17:08] <ogra> lag, just roll your kernel inside that chroot :)
[17:08] <lag> ?
[17:08] <lag> I do
[17:08] <ogra> mak install will put the modules in place
[17:08] <ogra> *make
[17:08] <lag> I don't do make install
[17:08] <lag> I have to do it manually
[17:08] <ogra> well, make modules_install
[17:08] <lag> Nope
[17:09] <lag> I build on a different <remote> machine
[17:09] <ogra> well, have an armel chroot there you can build in
[17:09] <lag> I do
[17:09] <ogra> wrap a script around it that spits our uImage/uInitrd
[17:09] <ogra> *out
[17:09]  * cpearson wonders if there are any Canonical guys at LinuxCon? Need someone to drink beer with tonight :)
[17:10] <ogra> cpearson, mdz i think and kees
[17:10] <cpearson> ogra: ping me with real names if you could
[17:10] <ogra> cpearson, what happened to the photo from prague btw ?
[17:10] <ogra> cpearson, matt zimmerman and kees cook
[17:10] <cpearson> http://ufgeek.wordpress.com/
[17:11] <ogra> (no secret :) )
[17:11] <ogra> awesome !
[17:11]  * cpearson does not have magic decoder ring for IRC nick to names :)
[17:11] <cpearson> ogra: thanks
[17:11] <rsalveti> lag: don't you need to generate the initrd.img first before creating the uIinitrd?
[17:11] <rsalveti> you said make uInitrd.img
[17:12] <kblin> cpearson: you clearly need to eat more geek flakes
[17:12] <cpearson> the marketing gig is making me soft
[17:14] <lag> rsalveti: Don't you use update-initramfs <kernel-image> to make uInitrd.img?
[17:15] <rsalveti> lag: yep, but I create the *initrd.img* file, not uInitrd.img
[17:16] <lag> http://ufgeek.wordpress.com/ - WTF!
[17:16] <lag> I have a stalker
[17:17] <cpearson> lag: damnit now you found me, I have to move to the other set of bushes outside your house
[17:18] <lag> ogra: cpearson: http://people.canonical.com/~ljones/lastsupper/
[17:18] <lag> rsalveti: Picky!
[17:19] <lag> rsalveti: But you get the idea
[17:19] <rsalveti> lag: yep, but the *u* on it means that you don't need to run mkimage :P
[17:19] <cpearson> ogra was confused... we had been drinking
[17:20] <ogra> heh
[17:20] <cpearson> and there was schnitzel
[17:20]  * ogra had duck though
[17:20] <cpearson> and an accordion
[17:20] <ogra> possibly a mad duck :)
[17:20] <cpearson> I'm sure we was briefly pissed... then they took his head off
[17:20] <lag> What was the lexicographic revelation? My spelling mistak?
[17:20] <lag> ;)
[17:22] <lag> cpearson: ?
[17:28] <cpearson> lag: the meaning of the middle F
[17:28]  * cpearson looks at the #linux-omap channel... man there are some strange people in there :)
[17:30] <GrueMaster> And we're not strange?  I'm offended.  :P
[19:01] <rsalveti> XorA|gone: regarding the texture from pixmap stuff, check https://wiki.linaro.org/Platform/UserPlatforms/2010-08-10 and http://www.mail-archive.com/mesa3d-dev@lists.sourceforge.net/msg11616.html to see how linaro and mesa guys are working with it
[19:01] <rsalveti> if you didn't read this already :-)
[19:02] <rsalveti> XorA|gone: alf__ and asac are working to understand if it's really needed to get this proprietary extension implemented on the driver side
[19:03] <rsalveti> or if it should just follow the common extensions like mesa guys are doing
[19:22] <XorA|gone> rsalveti: email me rather than talk here, Ill lose these logs before I get to read them
[19:23] <rsalveti> XorA|gone: your email?
[19:23] <XorA|gone> gg@slimlogic.co.uk
[19:23] <rsalveti> k