| rcn-ee | i belive we are... i'm not that high up, red river basin in north mn.. | 00:00 |
|---|---|---|
| * GrueMaster is in Oregon | 00:01 | |
| === XorA is now known as XorA|gone | ||
| rsavoye | if we had an east coaster we'd cover all the US time zones at least :-) | 00:03 |
| === orbarron is now known as orbarron|OoO | ||
| GrueMaster | we do. NCommander. | 00:03 |
| === bjf is now known as bjf[afk] | ||
| 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:15 |
| rsavoye | how to install ? | 00:17 |
| 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:18 |
| rsavoye | yep. I'll try it after it downloads | 00:20 |
| * NCommander waves | 00:23 | |
| NCommander | rsavoye: hey, how goes it? | 00:23 |
| rsavoye | stil trying to get my XM to run stably... | 00:23 |
| rsavoye | rcn-ee: you need to upgrade your net connection, an hour to download the uImage ? :-) | 00:29 |
| rsavoye | ah, now it's kicking in better.... | 00:30 |
| 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:31 |
| rsavoye | I know the problem,... I had to start my own rural ISP to get a connection at all... | 00:32 |
| rcn-ee | what's funny, digi-key is down the street, so they get 95% of the isp connection.. ;) | 00:33 |
| rsavoye | must be nice though if you need hardware :-) | 00:34 |
| rsavoye | does this new kernel run at 1Ghz ? | 00:51 |
| 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:53 |
| rcn-ee | some of the new 'base' pm stuff is in it.. | 00:54 |
| rcn-ee | so rsavoye what's the story? crash on boot? runs a little bit after boot? or eh it's still going? ;) | 01:19 |
| rsavoye | just ate dinner, let me try it | 01:25 |
| rsavoye | if I replace uImage with your image it doesn't boot. | 01:47 |
| rsavoye | I get funny characters to the serial port | 01:47 |
| rcn-ee | sweet, more things broken. ;) | 01:48 |
| 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:50 |
| rcn-ee | oh 115200 been the default, just getting my testsetup up again.. | 01:53 |
| 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:54 |
| 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:55 |
| rcn-ee | c++ apps are great for that. ;) | 01:56 |
| rsavoye | unfortunately... | 01:56 |
| rsavoye | funny enough when I build OpenJDL and Icedtea, the java code doesn't cause any problems, only C++ code | 01:57 |
| rcn-ee | well it's not a bad thing for stress testing. ;) | 02:01 |
| rsavoye | better us breaking it now than after the release. :-) | 02:02 |
| 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:04 |
| GrueMaster | He's in Germany. 3am. If he answers, I would be very surprised. | 02:05 |
| 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:06 |
| 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:07 |
| rcn-ee_lpt | the DONT_FLASH part was a patch i was working on but dropped.. | 02:08 |
| GrueMaster | Lucid wrote the kernel to nand, Maverick uses a 70M fat32 partition. It needs to have UBOOT_PART=<vfat partid> in it. | 02:09 |
| GrueMaster | especially for XM and systems w/o nand. | 02:10 |
| 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:11 |
| GrueMaster | Something like this? http://paste.ubuntu.com/475699/ | 02:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| GrueMaster | Now if TI (or one of their oems) were to make something like this...http://en.qi-hardware.com/wiki/Ben_NanoNote | 02:18 |
| 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:21 |
| 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:22 |
| rsavoye | ah, 500Mhz. oh well... :-) | 02:23 |
| rsavoye | still, sharing a beagle board in NZ is kindof slow... | 02:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| rsavoye | it's the exact opposite of real time... | 02:28 |
| GrueMaster | Just be thankful this hasn't become a standard yet. http://www.faqs.org/rfcs/rfc2549.html | 02:34 |
| GrueMaster | Although if MS ever hears about it... | 02:35 |
| rcn-ee_lpt | well, they'd just implement it after bsd. .;) | 02:36 |
| prpplague | GrueMaster: i thought they already implemented it in wince, that's why it runs so slow | 02:37 |
| GrueMaster | Heh. | 02:37 |
| 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:57 |
| rcn-ee_lpt | nope, just the uImage... lets see if it survies my aptitude test.. | 02:58 |
| rcn-ee_lpt | nope, crash.. can't wait for a production unit. ;) | 02:59 |
| rsavoye | aaarrrggg, same ol segfault. oh well... | 03:01 |
| rcn-ee_lpt | i get this... dss2 is broke.. http://pastebin.com/1UpFddvN | 03:02 |
| 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:04 |
| 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:05 |
| rsavoye | guess this will make me eager to test new kernels, hoping one works :-) | 03:06 |
| === JaMa|Zzz is now known as JaMa|Wrk | ||
| lag | rcn-ee: Are you here/ | 07:58 |
| lag | cooloney: Morning | 07:59 |
| cooloney | lag: morning, man | 08:12 |
| cooloney | you are very early | 08:12 |
| 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:13 |
| 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:14 |
| cooloney | lag: the latest TI release fixed one swap oops | 08:15 |
| cooloney | ndec: morning | 08:15 |
| ndec | cooloney: morning. | 08:16 |
| lag | ndec: Morning :) | 08:20 |
| lag | cooloney: When did you update? | 08:20 |
| ndec | lag: morning! | 08:20 |
| cooloney | lag: tim pull it last week. it is 2.6.34 based release | 08:21 |
| cooloney | not 2.6.35 | 08:21 |
| === hrw|gone is now known as hrw | ||
| hrw | morning | 08:23 |
| zumbi | hrw: hi | 08:39 |
| zumbi | hrw: where do you keep your compilers packaging | 08:40 |
| 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:45 |
| 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:46 |
| zumbi | (or you might not care on Debian?) | 08:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| zumbi | hrw: I have some dependency graph which might clarify package dependencies a little | 08:51 |
| hrw | ok | 08:51 |
| 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:53 |
| hrw | ok | 08:54 |
| hrw | what you use to visualize it? | 08:55 |
| lool | dotty | 08:56 |
| zumbi | dot -Tdot pkgdeps.dot | gvpr -c '' | dot -Tpdf -o pkgdeps.pdf | 08:56 |
| 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:57 |
| 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:58 |
| 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 | 08:59 |
| zumbi | back | 09:04 |
| zumbi | hrw: the most important think i wanted to show you from the graph is capability to rebuild non default compilers | 09:05 |
| 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:06 |
| 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:07 |
| hrw | phone... | 09:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| zumbi | lool: sounds fine | 09:15 |
| hrw | I think that we try to make a) == b) | 09:19 |
| hrw | at least thats my goal with ubuntu packages | 09:19 |
| 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:20 |
| hrw | my wife is refuelling our car for first time so I am remote helpdesk | 09:23 |
| 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) | 09:24 |
| lool | hrw: yeah, alternatives suck though :-/ but it's good to have that in place at least | 10:00 |
| 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:01 |
| hrw | armel-cross-toolchain 1.7 builds now. will fail anyway | 10:12 |
| hrw | 1.8 on a way | 10:22 |
| rcn-ee | lag pong | 12:44 |
| lag | Hi Robert | 12:45 |
| 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:46 |
| rcn-ee | for the xm, when the hardware is released, i'll send it to linux-omap, it'll probally get tweaked.. | 12:47 |
| lag | rcn-ee: Why don't you throw it up there now? | 12:50 |
| rcn-ee | i don't really have a good excuse. ;) | 12:52 |
| lag | The boards don't work without it | 12:54 |
| lag | Is that good enough? ;) | 12:54 |
| 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:56 |
| ogra | \o/ | 12:58 |
| * ogra sighs about oem-config | 12:59 | |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| hrw | or that binutils-arm-linux-gnueabi is also not ubuntu package | 13:13 |
| 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:14 |
| hrw | do not remember now | 13:15 |
| hrw | ogra: that script does same as I did - fetch pacakge and install | 13:15 |
| ogra | yeah | 13:16 |
| ogra | likely | 13:16 |
| hrw | but I play one dvd per year so... | 13:16 |
| * 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:17 |
| 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:18 |
| 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:19 |
| ogra | but thats 2.5 years ago and the model isnt produced anymore | 13:20 |
| lag | rcn-ee: Sounds good (I saw that your tabs are out, besides that it looked okay) | 13:25 |
| 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:28 |
| 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:37 |
| lag | rcn-ee: I'm commented on the bug with your information | 13:39 |
| lool | ogra: Around? | 13:54 |
| lool | ogra: Do you remember that discussion about changing the image generatin to output fat32 specifically? | 13:54 |
| 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:58 |
| 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 | 13:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:08 |
| 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:10 |
| lool | ogra: Well it's just that it checks for loop major device (7), but I'm using a mapper device (major 252) | 14:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:18 |
| lool | ogra: it's because mkdosfs has a different code path for files and for devices | 14:19 |
| lool | for files, it checks the size and defaults to 32 sectors and 64 heads | 14:20 |
| 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:21 |
| ogra | meh | 14:22 |
| 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:23 |
| ogra | (we want to provide the same image for blaze and panda but that requires different x-loader and u-boot) | 14:24 |
| lool | ogra: i'd rather fix mkdosfs | 14:25 |
| ogra | lool, in hardy ? | 14:25 |
| ogra | dont forget antimony is hardy | 14:25 |
| lool | ogra: Well we can certainly prepare a special fixed package to install there | 14:29 |
| ogra | indeed | 14:29 |
| === amitk is now known as amitk-afk | ||
| lag | ogra: If I want to test my bespoke kernels with the daily image - what's the easiest way? | 16:03 |
| 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:16 |
| hrw | someone remember how to tell "dch" to not use "ubuntu1" but bump version? | 16:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| rsalveti | yep, with rootstock you can give the kernel image to be used while creating the rootfs | 16:38 |
| lag | rsalveti: But I want to test it with the daily build | 16:39 |
| 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:40 |
| 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:41 |
| lag | rsalveti: I need to test them with the daily build's rootfs | 16:42 |
| 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:47 |
| lag | Does the daily build's rootfs have update-initramfs? | 16:49 |
| lag | And mkimage? | 16:49 |
| rsalveti | GrueMaster can easily check | 16:49 |
| GrueMaster | yes, they do. Sorry, had to step out for a bit. | 16:55 |
| ogra | lag, create a package, dpkg -i it | 16:56 |
| 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:57 |
| 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:58 |
| 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 | 16:59 |
| 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:00 |
| ogra | lool, seems the only thing that doesnt cope with our images is qemu here | 17:01 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 | |
| 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:10 |
| 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:11 |
| kblin | cpearson: you clearly need to eat more geek flakes | 17:12 |
| cpearson | the marketing gig is making me soft | 17:12 |
| lag | rsalveti: Don't you use update-initramfs <kernel-image> to make uInitrd.img? | 17:14 |
| rsalveti | lag: yep, but I create the *initrd.img* file, not uInitrd.img | 17:15 |
| lag | http://ufgeek.wordpress.com/ - WTF! | 17:16 |
| lag | I have a stalker | 17:16 |
| cpearson | lag: damnit now you found me, I have to move to the other set of bushes outside your house | 17:17 |
| lag | ogra: cpearson: http://people.canonical.com/~ljones/lastsupper/ | 17:18 |
| lag | rsalveti: Picky! | 17:18 |
| 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:19 |
| 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:20 |
| === rbelem is now known as rbelem-afk | ||
| lag | cpearson: ? | 17:22 |
| 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:28 | |
| GrueMaster | And we're not strange? I'm offended. :P | 17:30 |
| === orbarron|OoO is now known as orbarron | ||
| === hrw is now known as hrw|gone | ||
| === JaMa|Wrk is now known as JaMa | ||
| === sbambrough is now known as sbambrough-afk | ||
| === rbelem-afk is now known as rbelem | ||
| === sbambrough-afk is now known as sbambrough | ||
| 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:01 |
| 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:02 |
| rsalveti | or if it should just follow the common extensions like mesa guys are doing | 19:03 |
| XorA|gone | rsalveti: email me rather than talk here, Ill lose these logs before I get to read them | 19:22 |
| rsalveti | XorA|gone: your email? | 19:23 |
| XorA|gone | gg@slimlogic.co.uk | 19:23 |
| rsalveti | k | 19:23 |
| === hrw|gone is now known as hrw | ||
| === hrw is now known as hrw|gone | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!