**** BEGIN LOGGING AT Tue Aug 31 02:59:57 2010 Aug 31 03:47:52 Say, if I use an overlay and have an SD card write-protected, how long should it last? Aug 31 03:49:17 "how long" in what sense? Aug 31 03:49:28 Your overlay changes will last as long as your session lasts. Aug 31 03:49:59 Your SD media will last until entropy destroys the data (card- and environment- dependent) Aug 31 03:51:05 The latter is what I meant... media longevity. Aug 31 03:52:26 Then it depends on more factors than I can express. I can say "longer than if you write to it". Aug 31 03:53:03 longer if you stick your device in a lead-lined box (but not much, most of the radiation will be from components in the device, unless you put it somewhere particularly active) Aug 31 03:53:28 Putting it in a faraday cage will protect against some other interference. Aug 31 03:53:42 And so on... Aug 31 03:54:28 (using a shielded SD card, with an internal grounded faraday cage surrounding the flash might help, but that requires manufacturer connivance) Aug 31 03:55:32 What sort of time-span would the wearing-out likely be? 1 year? 2? 10? Aug 31 03:58:51 I can't answer that. Ask your SD manufacturer. Aug 31 04:00:15 ah. Aug 31 04:00:25 I used to work at a data manipulation firm. We sold the results of queries against our datasets. We bought the highest-reliability drives we could. Nonetheless, at my next job interview, when asked "Which commands do you use the most in the shell", I was told I must not use UNIX much because fdisk was in my answers. Aug 31 04:00:46 These were drives with multi-year MTBF ratings, but we had 5-10 failures a week. Aug 31 04:01:18 Is that due to luck, or just due to large sample size? Aug 31 04:01:39 Anyway, from a software perspective, if you only write to the flash once, you'll never end up with eraseblock issues, or wearing considerations, etc. Aug 31 04:01:44 large sample size. Aug 31 04:02:07 It was several TB of data stored over 9GB drives (the largest available at the time) Aug 31 07:00:44 Say, I figured out what was up with the hardlink troubles: http://lkml.org/lkml/2010/6/23/25 Aug 31 07:23:40 morning Aug 31 07:24:26 persia: thousands of harddrives? Aug 31 07:25:18 Yep. All wired up through cabinets to a 6-way Turbolaser @ 600MHz. Bug iron for the day :) Aug 31 07:25:31 s/Bug/Big/ Aug 31 07:26:54 impressive Aug 31 08:25:49 Say, that Airlife 100... what're the chances of getting Ubuntu on that? Aug 31 08:26:08 http://carrypad.com/productinfo/?id=606 Aug 31 08:27:16 * persia looks Aug 31 08:28:46 "Qualcomm SnapdragonTM QSD8250 (GSM/UMTS) 1GHz" Aug 31 08:30:25 http://www.qualcomm.com/products_services/chipsets/snapdragon.html completely fails to indicate ISA support. Aug 31 08:30:46 Anyway, if it's ISA-compatible, it's a kernel away. Aug 31 08:30:51 If not, too bad. Aug 31 08:31:04 Heavy though, at 1kg for a 10" notebook. Aug 31 08:31:34 Oh, and low-color screen (65,536 colors) Aug 31 08:31:47 Bleh. Aug 31 08:31:58 Indeed. Aug 31 08:32:10 I'm eyeing the Tegra2 stuff... I just wish they'd use Ubuntu instead of Android. Aug 31 08:32:10 Lots better 10" low-end laptops out there. Aug 31 08:32:23 snapdragon is armv7 Aug 31 08:32:45 hrw, *all* snapdragon? Fully compliant? I know it's not coretex. Aug 31 08:39:41 afaik 8250 is armv7 Aug 31 08:40:40 but I may be wrong Aug 31 08:47:02 That likely makes it ISA-compatible then, making installing Ubuntu mostly a matter of finding a kernel, and knowing how to boot your desired kernel. Aug 31 12:19:04 ogra: what happened with our builders? Aug 31 12:19:24 the email I got has now messages :-) Aug 31 12:19:28 *no Aug 31 12:20:30 rsalveti, they were dead Aug 31 12:20:36 all solved now Aug 31 12:21:01 ogra: oh, cool Aug 31 12:26:08 lag, if bug 625108 is solved with ES2 HW you dont need to work on it Aug 31 12:26:10 Launchpad bug 625108 in linux-ti-omap4 (Ubuntu) "System hangs when you run ifconfig usb0 up and ifconfig usb0 down (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/625108 Aug 31 12:26:20 we'll switch everything to ES2 after beta Aug 31 12:27:37 I'm not working on it per-say, rather taking responsibility for it Aug 31 12:27:50 ah, k Aug 31 12:28:28 ogra: Don't worry, I'm not wasting my time, it's too precious Aug 31 12:28:51 heh Aug 31 12:49:22 Who's tested the ES2.0? Aug 31 12:49:54 lag: I did Aug 31 12:50:07 GrueMaster also tested Aug 31 12:50:20 [ 521.163452] omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX Aug 31 12:50:20 [ 521.221771] omapdss DISPC error: SYNC_LOST_DIGIT Aug 31 12:50:25 Did you get that? Aug 31 12:50:55 That happened during oem-config and the monitor turned itself off Aug 31 12:51:01 lag: nops Aug 31 12:51:17 That was with my Phillips monitor Aug 31 12:51:21 I'll try it with my LG one Aug 31 12:51:41 but was it working with correct resolution before turning itself off? Aug 31 12:52:00 rsalveti: Yeah, it looked fine Aug 31 12:52:20 When I initially started it up, it configured the rebooted and there was nothing Aug 31 12:52:33 Then I restarted it with my own boot.scr and it worked Aug 31 12:52:47 5 mins into oem-config and [pow] Aug 31 12:52:56 our 2.6.35 tree should have most of the hdmi fixes from robclark, so it should work better Aug 31 12:53:00 at least it worked fine with my LG monitor Aug 31 12:53:13 rsalveti: Nope, this is your kernel ;) Aug 31 12:53:37 lag: should be ok also Aug 31 12:53:48 Clearly it isn't :) Aug 31 12:53:59 bugs :-) Aug 31 12:54:07 Arggggggggggggggggg BUGSSSSSSSSS Aug 31 12:54:33 mythripk: Afternoon Aug 31 12:54:45 lag: test with your lg to see if you get a similar bug Aug 31 12:54:56 rsalveti: I'm doing so now Aug 31 12:56:25 rsalveti: That heartbeat LED is annoying Aug 31 12:56:40 lag: haha :-) Aug 31 12:56:45 boom boom ... boom boom ... boom boom ... Aug 31 12:56:55 at least you now know that the board is up and running :-) Aug 31 12:57:09 boom boom ... boom boom ... boom boom ... Aug 31 12:57:25 lol Aug 31 13:00:13 rsalveti: Looks stable enough on the LG Aug 31 13:00:42 as i said from the beginning, TI shoudl just ship proper monitors with the boards Aug 31 13:01:00 haha Aug 31 13:01:05 would have saved so much work for so many people :) Aug 31 13:01:16 lag: so probably the issue is now related with phillips monitors Aug 31 13:01:35 rsalveti: Could be Aug 31 13:01:43 * rsalveti imagining a huge box getting into his house with the monitor and the board Aug 31 13:01:48 who busy phillips anyway Aug 31 13:01:49 I only have those two lines to tell me anything though Aug 31 13:01:52 *buys Aug 31 13:02:05 lag: put the debug argument and try again Aug 31 13:02:07 Canonical do Aug 31 13:02:17 silly canonical :P Aug 31 13:02:23 rsalveti: I will (still testing with LG) Aug 31 13:02:28 lag: ok Aug 31 13:03:19 rsalveti: Same thing with LG Aug 31 13:03:44 [ 566.867828] omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX Aug 31 13:03:44 [ 566.925109] omapdss DISPC error: SYNC_LOST_DIGIT Aug 31 13:06:05 lag: that's weird Aug 31 13:06:05 lag: could be you or your board again Aug 31 13:06:05 :P Aug 31 13:06:23 rsalveti: No way! Aug 31 13:06:59 rsalveti: Two boards is unlucky enough, three would be ridiculous Aug 31 13:10:24 haha Aug 31 13:19:17 lag: do you have x-loader w/ DDR timings tweaks and 1gb support? Aug 31 13:19:44 without that, I don't think DSS gets enough memory bandwidth to feed a 1920x1080 hdmi monitor.. Aug 31 13:19:44 robclark: Probably not? Aug 31 13:19:57 * robclark finds link Aug 31 13:20:03 I'm suing the ones rsalveti gave me Aug 31 13:20:30 oh.. hmm.. es1 or es2? Aug 31 13:20:59 lag: do you know exactly which one you got from me? Aug 31 13:21:14 I built 2, one with 1gb and another with current gitorious tree Aug 31 13:22:03 rsalveti / lag: looks like last two commits are not on official tree yet: http://gitorious.org/~robclark/pandaboard/robclarks-x-loader/commits/omap4_panda_es2.0-1gb Aug 31 13:22:26 but I was seeing lots of GFX (and VID when doing video playback) underflows without those last two Aug 31 13:22:39 (and last one lets you build w/ highmem and get a gig) Aug 31 13:22:53 brb Aug 31 13:22:56 * robclark gets coffee Aug 31 13:24:42 lag: http://people.canonical.com/~rsalveti/maverick/boot/es2/x-load.bin-1gb Aug 31 13:24:48 did you test with this one? Aug 31 13:25:11 this binary is from robclark's tree Aug 31 13:25:28 rsalveti: It doesn't look familiar Aug 31 13:25:39 rsalveti: I'm using the one you linked me to Aug 31 13:25:56 rsalveti: The one with u-boot-with-ubuntu-patches.bin Aug 31 13:27:29 argh, disconnected, very unstable gsm connection Aug 31 13:27:49 * rsalveti at linuxcon brazil Aug 31 13:34:15 lag: test with: Aug 31 13:34:18 http://people.canonical.com/~rsalveti/maverick/boot/es2/MLO-1gb Aug 31 13:34:26 and http://people.canonical.com/~rsalveti/maverick/boot/es2/u-boot.bin-with-ubuntu-patch Aug 31 13:34:44 rsalveti: Doing that now Aug 31 13:35:01 cool Aug 31 13:35:21 ogra said that the vfat is trashed on first boot, do I need to change it somewhere else other than /boot? Aug 31 13:37:18 lag: the vfat is trashed with this u-boot, and fixed with upstream one Aug 31 13:37:35 lag: so grab the files, copy to a folder, format the partition and copy the new files Aug 31 13:37:37 rsalveti: No, I mean formatted Aug 31 13:37:56 ogra: ... Aug 31 13:40:44 rsalveti, vfat is reformatted in jasper to make sure x-loader ends up in the first block after re-partitioning Aug 31 13:40:59 ogra: oh, true, right Aug 31 13:41:07 saw the code yesterday Aug 31 13:41:13 ogra: So I need to update the one in the boot partition and ? Aug 31 13:41:30 we shouldnt need that for omap4 anymore, but omap3 definitely requires it Aug 31 13:41:46 lag, kernel and initrd come from /boot in the rootfs Aug 31 13:41:55 err, wait Aug 31 13:41:56 And x-loader? Aug 31 13:41:57 no Aug 31 13:42:03 you dont need to do anything Aug 31 13:42:11 it gets copied from vfat to a tmpfs Aug 31 13:42:17 and gets restored from there Aug 31 13:42:20 Well I'm replacing /boot/boot.script with my own one for a start Aug 31 13:42:32 Ah, that's good Aug 31 13:42:40 So it's just boot.script that I need to update Aug 31 13:42:48 initrd gets re-rolled after oem-config is run Aug 31 13:42:56 *then* it uses the stuff from /boot Aug 31 13:43:09 Okay Aug 31 13:43:10 jasper just uses the tmpfs Aug 31 13:43:20 I notice that /boot/boot.script is headless Aug 31 13:43:38 Is the header attached during installation? Aug 31 13:43:51 flash-kernel runs mkimage Aug 31 13:43:57 k Aug 31 13:44:02 Then I'm all set Aug 31 13:44:05 /boot/boot.script is headless on purpose Aug 31 13:44:11 *headerless Aug 31 13:44:23 ogra: I didn't think anything different Aug 31 13:44:36 imagine menu.lst here ... its the file a user should be able to edit for canges Aug 31 13:44:57 and then just run flash-kernel to update the actual boot.scr Aug 31 14:04:25 lag: I'll retest bug 615400 after I test beta. It requires a bit of work to test, as It involves a full upgrade from Lucid (which is really the only time you'd run into it). Aug 31 14:04:26 Launchpad bug 615400 in flash-kernel (Ubuntu Maverick) (and 1 other project) "package initramfs-tools 0.97.2ubuntu1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1 (affects: 1) (heat: 8)" [Undecided,Triaged] https://launchpad.net/bugs/615400 Aug 31 14:05:01 GrueMaster: No rush :) Aug 31 14:05:24 I'm just going through my emails & retest requests. :P Aug 31 14:11:37 GrueMaster, Were you ever able to replicate bug #613591 ? Aug 31 14:11:38 Launchpad bug 613591 in jasper-initramfs (Ubuntu) "Jasper sometimes fails to resize root partition on omap4 (affects: 1) (heat: 167)" [Undecided,New] https://launchpad.net/bugs/613591 Aug 31 14:11:54 Not lately. Aug 31 14:29:50 * persia grumbles about unreproducible bugs Aug 31 14:42:50 ogra: /boot/boot.script - it gets written over Aug 31 14:43:02 Where does it come from? Aug 31 14:46:21 lag: it is generated by jasper during first boot. Aug 31 14:46:38 How do I un-generate it? Aug 31 14:46:45 It's a pain in the ass Aug 31 14:47:23 If you are running our preinstalled images, it is created the first time it boots, and not touched again. Aug 31 14:47:41 Anyone have a jasper-based boot on a beagle with a resolution *other* than 1280x720 ? I'd appreciate any testing of the patch on bug #605831 Aug 31 14:47:42 Launchpad bug 605831 in jasper-initramfs (Ubuntu Maverick) (and 1 other project) "Resolution should be taken from /proc/cmdline if provided (affects: 1) (heat: 8)" [Medium,Triaged] https://launchpad.net/bugs/605831 Aug 31 14:48:12 persia: isn't that the default in the boot image? Aug 31 14:49:27 I'm still pulling dailies. Will test when I can, if I can. Aug 31 14:57:16 GrueMaster, The patch is supposed to allow you to set an alternate default on the kernel command line. What I don't know is whether it works for someone with such hardware. Aug 31 14:58:15 Ideally, we shouldn't need any cmdline parameter for display resolution. Aug 31 15:01:49 Yeah, well. That requires better X autodetection than has been historically available Aug 31 15:02:06 But I'd rather allow folks to specify something other than default, as long as it needs to be hardcoded. Aug 31 15:04:38 I've been having a lot of problems getting maverick installed/working on this laptop and was wondering if there are updated images (tried alpha-3), or perhaps another method I could use to get it installed ? Aug 31 15:05:08 devilhorns: What laptop? Arm based? Aug 31 15:05:45 GrueMaster, no, this is x86. trying to get maverick installed on it so that I can do some development for arm devices Aug 31 15:06:28 Unfortunately, this channel is focused on Arm porting issues only. But I'm sure there is someone in #ubuntu-desktop that could help. Aug 31 15:06:52 We can help on the arm side. Aug 31 15:06:55 :P Aug 31 15:07:23 yea ... alright, guess I am stuck w/ a broken box then, but thanks :/ Aug 31 15:09:10 Not necessarily. We're just not the right group to field x86 issues to. I also have a new x86 netbook that has issues with Maverick, but the people in #ubuntu-desktop are better equipped to help. Aug 31 15:09:56 fair enough :) Aug 31 15:11:39 Or the folks in #ubuntu-testing might be inclined to help (although they'll want you to test pre-betas) Aug 31 15:11:59 persia, hmmm, those may actually work, thanks :) Aug 31 15:12:14 persia, seems I have better luck w/ alpha or pre-beta than I do w/ any releases :) Aug 31 15:12:46 devilhorns: The trick is to get really fussy about the regressions between beta and release :) Aug 31 15:13:15 persia, lol, well not in my nature to get fussy :) Aug 31 15:45:04 ogra, GrueMaster: Why is x-loader.bin deleted? Aug 31 15:45:30 robclark: Have you tried to use our images? Aug 31 15:46:51 Huh? Aug 31 15:47:05 Where is it deleted? Aug 31 15:47:16 On first boot I guess Aug 31 15:47:25 boot.scr MLO u-boot.bin uImage uInitrd Aug 31 15:47:30 That's all that's left on the card Aug 31 15:47:37 MLO is x-loader Aug 31 15:47:55 Unless I am missing something. Aug 31 15:47:59 You are Aug 31 15:48:20 Apparently we need robclark's new fan-dangled x-loader.bin Aug 31 15:48:23 Which I loaded Aug 31 15:48:53 Then, something (usually bloomin' Jasper) deletes it Aug 31 15:49:52 No, jasper just doesn't know about it. Aug 31 15:50:05 for file in MLO boot.scr u-boot.bin uImage uInitrd; do Aug 31 15:50:30 That's from the section that reformats the vfat partition with proper CHS info. Aug 31 15:51:24 (why he doesn't just do "cp MLO boot.scr u-boot.bin uImage uInitrd * " I don't know Aug 31 15:51:31 Try naming the new fan-dangled x-loader.bin "MLO" Aug 31 15:51:46 That was my next suggestion. Aug 31 15:51:51 lag: kernel images.. or filesystem? Aug 31 15:52:14 I pretty much only build my own kernels.. and filesystem I use I get from ndec and crew Aug 31 15:53:06 GrueMaster, Because of the sync() between each file write: it's a filesystem coherency concern (FAT isn't known to be as safe as some filesystems) Aug 31 15:53:27 ah. Aug 31 15:54:04 I can try to name x-loader.bin -> MLO and see if that works Aug 31 15:54:04 fwiw persia, the MLO is signed.. so I'm not sure if you can just cp x-loader.bin MLO Aug 31 15:54:13 Ah Aug 31 15:54:19 Then we need a better solution Aug 31 15:54:39 I don't know how this worked for rsalveti ? Aug 31 15:54:48 Jasper needs to be generalised, but that's probably not safe within maverick timeframe. Aug 31 15:54:53 lag: in x-loader tree there is a signGP script which can be used to make a MLO from an x-loader.bin.. Aug 31 15:55:14 I've not looked much at how it works.. but might be interesting to you Aug 31 15:55:47 but.. why do you have an x-loader.bin instead of x-loader.bin.ift (which is same as MLO)? Aug 31 15:56:28 I've never seen a x-loader.bin.ift Aug 31 15:57:37 usually it is renamed immediately to MLO ;-) Aug 31 15:57:46 I guess you only see the ift if you build x-loader yourself Aug 31 15:57:58 Which I haven't done Aug 31 15:58:18 Can you make me a fan-dangled MLO? Aug 31 15:58:31 lag: where did you get the x-loader.bin from? Aug 31 15:58:37 robclark Aug 31 15:58:48 did I send you an x-loader.bin? Aug 31 15:58:49 ah Aug 31 15:58:58 I probably meant to send an MLO.. opps Aug 31 15:59:20 Actually, I think you gave it to rsalveti, and he gave it to me Aug 31 16:00:10 lag: I just mailed to you a MLO Aug 31 16:00:15 In fact Aug 31 16:00:18 Look: http://people.canonical.com/~rsalveti/maverick/boot/es2/ Aug 31 16:00:26 That's why it worked for rsalveti Aug 31 16:00:38 He's been trying to stitch me up! ;) Aug 31 16:00:43 Thanks robbiew Aug 31 16:00:46 Doh Aug 31 16:00:49 heheh Aug 31 16:00:54 Thanks robclark Aug 31 16:00:59 np Aug 31 16:01:13 Luckily robbiew isn't anyone important ;) Aug 31 16:01:18 Eeeeeeeeeeeeeeeeek! Aug 31 16:02:07 Now would any of us try to confuse our kernel dev's? Aug 31 16:03:09 I'm guessing rsalveti didn't know any better Aug 31 16:03:23 heh...I'm not important at all ;) Aug 31 16:03:24 I'll give him the benefit of the doubt Aug 31 16:03:42 robbiew: Sorry for the disturbance :D Aug 31 16:03:50 robbiew: Bloomin' tab complete Aug 31 16:03:55 no worries Aug 31 16:07:03 Tab complete works for people that know how to use it properly. ;p Aug 31 16:07:20 * GrueMaster hides. Aug 31 18:08:25 * rsalveti reading the backlog Aug 31 18:13:49 lag: you should use MLO-1gb Aug 31 18:13:56 as I pointed later for you Aug 31 18:14:12 rsalveti: I think he figured that out. Aug 31 18:14:15 that was compiled using robclark's tree and etc Aug 31 18:14:23 the harder way Aug 31 18:14:43 too bad I wasn't on-line Aug 31 18:14:54 lag: did it work better with your monitor now? Aug 31 18:16:12 GrueMaster: are you still facing the hang over the second boot at your images? Aug 31 18:17:50 Not sure. Haven't gotten that far yet. Aug 31 18:18:10 Was having desktop issues. Had to upgrade/reboot. Aug 31 18:19:03 One issue that seems to have resolved itsself is that the XM failed to load oem-config. Working now after zeroing out the microSD and reflashing. Aug 31 18:19:40 hm, ok Aug 31 18:19:59 panda just finished oem-config. After it logs in, I'll reboot and see. Aug 31 18:20:29 * GrueMaster wishes for more SD card readers to help parallelize reflashing. Aug 31 18:21:26 I discovered yesterday that using my built-in sd slot from my eeepc lets me write the sd image much faster than the usb one I have Aug 31 18:21:33 Hrm. the home button ENOWORKS. Aug 31 18:21:59 Yea, I would use the one on my netbook, but it is not supported by the kernel yet. Aug 31 18:22:47 And I'm out of both power plugs & desk space to attempt to resuscitate my old laptop. Aug 31 18:34:06 Hey guys. Just checked if I still get the wrong default gdm session. Used yesterday's image and it the error seems to persist Aug 31 18:34:30 -it Aug 31 18:41:30 Is that after running "/usr/lib/gdm/gdm-set-default-session une-efl"? Aug 31 18:41:53 GrueMaster: no. after that it always works Aug 31 18:42:22 Then it isn't an image issue. That cmd is run during our first-boot process. Aug 31 18:42:55 Ah ok then I can close the bug Aug 31 18:46:06 GrueMaster: It's not ran by oem-config right ? Aug 31 18:46:41 No, it is a part of jasper scripts that run in our initrd. Aug 31 18:47:09 GrueMaster: Ok. Have you considered including /etc/gdm/custom.conf with the according session line directly in the rootfs ? Aug 31 18:47:44 It would break other images that actually support 3D. Aug 31 18:50:33 Which use the exact same omap4 image ? Aug 31 18:51:32 Let me restate... Why do you want to keep machine specific configuration outside of the actual rootfs ? Aug 31 18:51:34 The basic image build process is the same across all arches that generate Ubuntu Netbook images. Aug 31 18:53:07 The preinstalled images for omap are identical to the live images for other armel platforms, and near identical to x86 images (we don't include openoffice as it is currently not building). Aug 31 18:54:13 Ah I have been wondering about the oo.org lack :) Aug 31 18:54:57 You said defaulting to une-efl in the rootfs (stock configuration) will break other images (machines?) that support 3d Aug 31 18:56:22 That raises two questions for me. Is it no the other way around i.e. efl session works on all machines ? Are the 3d machines not using an initramfs as well that could write the 3d session ? Aug 31 18:59:35 The problem is that the default launcher is Unity, which requires clutter (3D). Over 95% of the users of the base image will have support. And currently, the desktop team that is developing the core UNE don't have enough manpower to develop a clean way to determine which launcher to use by default. It will probably happen next cycle though. Aug 31 19:01:58 Ok so people are thinking about that already. Aug 31 19:02:21 That's good. I guess in the future you will stumble across more such machine specific questions Aug 31 19:03:27 What's the name of the 3d gdm session ? Aug 31 19:05:03 It worked last cycle, but the UNE developers are creating a new 3D launcher from scratch, plus there were gnome changes. At this point, we're too close to release to have a permanent solution added, so a little hacking is required. Aug 31 19:05:52 For me that's absolutely no problem. I have quite a list of items I need to apply for my machine to be usable anyway Aug 31 19:10:33 GrueMaster: What do you think? Keep the bug 'incomplete' until a global solution to write the correct gdm config for the target is present or close it because it is fixed for the 'supported' machines ? Aug 31 19:10:48 bug 625591 Aug 31 19:10:49 Launchpad bug 625591 in jasper-initramfs (Ubuntu) "[ARM] ubuntu-netbook defaults to 3D session even after "fix" by jasper-initramfs (affects: 1) (heat: 10)" [Medium,Incomplete] https://launchpad.net/bugs/625591 Aug 31 19:14:07 Since you have your own kernel and boot method, you might take a look at our dove images instead. The next build should have a temporary fix. But it is a live image (similar to our cd images on x86). Aug 31 19:31:08 GrueMaster: Cool. Right now I am solving some kernel issues: WiFi driver is not detected by NetworkManager, Suspend is broken, framebuffer driver version is incompatbile with xf86-video-msm. Soon as I have these things solved and tested in the omap4 image I can try dove Aug 31 19:32:08 I am also going to look into utouch. I installed it already but it does not work out of the box. The test programs claim my touchscreen input device is not suported. I have yet to figure what utoutch expectes on the kernel driver level. Aug 31 19:33:17 I am wondering about a known working utouch touchscreen device driver so I can compare Aug 31 19:42:18 no idea. Not something I can readily test. Aug 31 19:50:54 GrueMaster: posted a bug on it :) Aug 31 20:23:18 hum, arm-linux-gnueabi-objcopy doesn't appear to work on lucid-amd64... Aug 31 20:24:08 rsavoye: is that CS toolchain ? Aug 31 20:24:26 it's from a ppa,. let me check Aug 31 20:24:48 deb http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ ./ Aug 31 20:25:12 the object file was produced on an imx51 maverick based board Aug 31 20:25:22 it works natively, it's just slow Aug 31 20:26:29 heh I remeber a blog entry from hrw|gone about starting to compile cross toolchains for canonical Aug 31 20:26:32 so I tried to dissasemble it on the machine that was NFS exporting the build directory to the board Aug 31 20:26:44 this is from his repo Aug 31 20:26:58 yeah Aug 31 20:27:09 it doesn't like the magic number I think Aug 31 20:27:16 it says it's an unsupported type Aug 31 20:27:38 hm so far I only compiled natively Aug 31 20:27:45 on my machine in maverick Aug 31 20:28:15 me too, but the object files were on an NFS partition so I tried there for grins Aug 31 20:28:29 I' Aug 31 20:28:37 ll try on a 32bit machine for another test Aug 31 20:28:55 hrw|gone: sure has tested the cross toolchains on amd64 host machine. People would have come across the problem already Aug 31 20:29:15 at least the object file is produced from a GPL'd program :-) Aug 31 20:29:58 it might work if you built it al cross. here it was built on maverick-arm, and objdump'd on lucid-amd64 Aug 31 20:30:04 which should work fine Aug 31 20:34:37 objdump: Can't disassemble for architecture UNKNOWN! Aug 31 20:34:57 yep, it dissasemnles fine on a 32bit host, but fails on amd64 Aug 31 20:35:03 guess I get to file a bug report Aug 31 20:37:24 hrw|gone: might help you Aug 31 20:56:47 davidm ? Aug 31 21:04:36 rsalveti: Yes, it now works Aug 31 22:38:57 GrueMaster, jasper isnt using cp because for omap3 we need to make sure MLO ends up in the very first block of the vfat (i used to just have a separate function for MLO but that didnt make sense so i wrote that loop) Aug 31 22:39:54 ok. Doesn't matter at this point. Issue was resolved. Aug 31 22:40:30 yep just wanted to explain why it is as it is Aug 31 22:40:56 panda shouldnt need that anymore but jasper is used on both, omap3 and 4 Aug 31 22:44:46 Is there a list of supported hardware ? Aug 31 22:44:53 ARM hardware Aug 31 22:45:15 I keep getting confused about all the boards you guys are talking about Aug 31 22:53:33 I'm not sure that we have one readily available. We have two main focuses: build & support Ubuntu on armv7 based hardware, and build & support images on specific systems. Aug 31 22:55:00 First part is carried across releases. Second one can change every cycle due to contracts. Aug 31 22:55:48 And sometimes it changes mid-cycle. Aug 31 22:56:33 But for the most part, we are driving towards armv7 support in the entire Ubuntu pool of applications. Aug 31 22:58:50 Does that make sense? Aug 31 23:37:42 I'm waiting for that darn "panda" to become available. Aug 31 23:37:58 Though, if I were to have an ARM file server, I'd want one with native gigabit ethernet and SATA, not USB stuff. Aug 31 23:42:05 DanaG, There are always rumours of new cool stuff. Currently, I believe you can get this retail for ARMv6, but not ARMv7. Aug 31 23:43:10 http://wiki.debian.org/ArmHardFloatPort/VfpComparison Aug 31 23:43:31 I know that "Panda" is something that actually exists, but is supposedly under NDA. Sep 01 00:06:54 GrueMaster: Yes makes perdect thanks. Thank you Sep 01 00:07:33 s/perdect/perfect/ Sep 01 00:07:57 GrueMaster: Well thanks for the explanation. Sep 01 00:08:02 It seems like I need a break. **** ENDING LOGGING AT Wed Sep 01 02:59:57 2010