**** BEGIN LOGGING AT Wed Jan 13 02:59:57 2010 Jan 13 03:46:15 would it be possible to run Ubuntu ARM on a EP93XX? They have ARMv920t processors with MaverickCrunch FPUs, although I wouldn't mind not being able to use the FPU. Jan 13 03:59:53 debio264: Do you know which ARM instruction set those implement? A quick web search isn't answering this for me. Jan 13 04:00:22 they run EABI, I know that much Jan 13 04:00:38 beyond there, it's ARMv9 Jan 13 04:00:41 not sure what you mean Jan 13 04:01:02 I think ARM9 is ARMv5, but I'm not 100% sure. Jan 13 04:01:20 Basically, there are several revisions of the ARM core (e.g. ARM9, ARM11, etc.) Jan 13 04:01:43 And there are several revisions of the instruction set (e.g. ARMv5, ARMv6, etc.) Jan 13 04:01:59 I'm not 100% sure of the mapping, although I remember wikipedia having a decent entry about it. Jan 13 04:02:26 well, the Debian armel port apparently runs on these boards Jan 13 04:02:27 But if it is ARMv5, then you would only be able to run Ubuntu 9.04, as 9.10 requires ARMv6 and 10.04 will require ARMv7. Jan 13 04:02:30 I'm reading up on that Jan 13 04:02:38 Debian armel is ARMv4 Jan 13 04:02:54 ah Jan 13 04:03:11 It's very loosely parallel to the differences between 486, 586, 686, etc. (but the specifics are completely different) Jan 13 04:03:11 are there any plans to change the armel minimum instruction set? Jan 13 04:03:49 There have been plans to do that for each release, but always in the direction of only supporting newer instruction sets, so it's unlikely that ARMv5 will be supported in future versions. Jan 13 04:04:10 no, I mean on the Debian side Jan 13 04:04:45 (I've already been stung by the Ubuntu changes as my ARMv5 Sheevaplug used to run Jaunty) Jan 13 04:05:12 I guess I'm probably better off with Debian, actually, if the Ubuntu requirements are going to keep rising Jan 13 04:07:34 I have heard some vague rumours that Debian may move to ARMv5 at some point, but nothing concrete, and I don't expect that would happen until there were vanishingly few devices still working that required ARMv4 Jan 13 04:07:52 But yeah, if you're using ARMv5 devices, Debian is probably going to be more satisfying. Jan 13 04:10:33 persia: okay, thanks for your help Jan 13 09:17:35 JamieBennett: In your casper perf branch, I think you can replace the "chroot /root cat " with just "cat " Jan 13 09:18:43 Thanks for looking lool. The branch doesn't work at the moment as I got pulled of it for something else so there are probably other fundamental errors too but it gives an idea of the direction. Jan 13 09:31:00 wow Jan 13 09:31:11 ? Jan 13 09:31:11 * ogra just does the first SATA install on his babbage Jan 13 09:31:25 Bit faster that way, is it? Jan 13 09:31:27 with a side-by-side resizing variant Jan 13 09:31:55 i dont expect it to be much faster since its still routed through USB, but that everything just works is impressing :) Jan 13 09:32:23 even though ... Jan 13 09:32:39 it seems to be faster ... 32% after 2 min is something i havent seen yet Jan 13 09:32:48 (32% of copying files) Jan 13 09:33:00 41 now Jan 13 09:33:10 hmm,. its definately faster Jan 13 09:33:36 USB isn't usually the bottleneck, it's that most people who install to "USB" are installing to flash, and the FTL tends to be slow. Jan 13 09:33:58 i never managed to get more than 20MB/s throughput Jan 13 09:34:04 ogra: very happy to know that Jan 13 09:34:10 no matter if the attached disk was usb or sata Jan 13 09:34:12 ogra: writing to what media? Jan 13 09:34:21 persia, doesnt matter Jan 13 09:34:31 rotary sata vs usb key Jan 13 09:34:39 both always had the same speed Jan 13 09:34:45 hrm. It ought to have mattered. rotary SATA *should* be faster than flash for bulk write. Jan 13 09:34:51 that doesnt seem to be the case anymore Jan 13 09:34:58 asac: You said in #506761 that you bumped the partition size; I guess the vfat one? Looks like another bug in the uboot vfat code (was already broken with fat16 versus 32) Jan 13 09:35:22 48% after 5 min install time is definately a new record though Jan 13 09:36:07 lool, he said that at 6am ... i bet he'S asleep ;) Jan 13 09:36:12 :) Jan 13 09:37:03 wow, even the slideshow survived until 53% ... it is usually done at 15 :) Jan 13 09:37:17 I think I nailed ffmpeg Jan 13 09:37:33 \o/ Jan 13 09:39:10 god that install is fast ... Jan 13 09:42:14 80% after 12min ! Jan 13 09:42:54 * ogra wishes he had not chosen a german install ... downloading langpacks will slow everything down Jan 13 10:12:54 ok, that was 42min ... (vs 75min in karmic to a USB key) ... lets see if it boots now :) Jan 13 10:13:39 Probably your USB key isn't as fast as a hard disk though Jan 13 10:14:01 There is a difference between SATA on board and over USB in my experience, but not big Jan 13 10:14:04 at least on b2.5 Jan 13 10:16:16 well, but 30min ? Jan 13 10:16:31 i did SATA installs before in karmic (that couldnt start gdm) Jan 13 10:16:39 they were not that fast Jan 13 10:17:34 It's kind of a pitty that I can't dchroot on the porter box Jan 13 10:18:01 why ? Jan 13 10:18:08 It fails Jan 13 10:18:08 are you using the right runes ? Jan 13 10:18:19 ogra: Try it out :-) Jan 13 10:18:28 I think cjwatson ran in the same issues when he looked into qt4-x11 Jan 13 10:18:38 there was a trick i forgot about (since i never used the porter box) Jan 13 10:18:55 something like dchoot -l lucid ? Jan 13 10:19:04 or -c lucid ... dont know anymore Jan 13 10:19:17 ogra: Try it! Jan 13 10:19:45 It just aborts with a mutex assertion Jan 13 10:19:52 I'm pretty sure we hadit in the past, but it would still login Jan 13 10:20:19 yeah, that was the issue you can work around with the option Jan 13 10:20:57 I bet our kernel is too old Jan 13 11:05:03 Has anyone been getting slow networking with the new imx51 kernel? I'm now getting only ~100kB/s and package updates take an age. Jan 13 11:05:15 I'm not sure if the kernel upgrade caused this, but my other boards are fine Jan 13 11:05:33 works fine here, i'm just installing chromium Jan 13 11:05:57 weird... maybe it's caused by something else Jan 13 11:06:05 though i switched to a usb wlan key after about 1h but didnt notice any slowness before Jan 13 11:06:41 I'll assume it's not a problem for now; I'll see if it keeps happening. Jan 13 11:07:34 i'm using a fresh install from the 12.2 image though ... Jan 13 11:07:45 might be userspace if you see it on an upgraded system Jan 13 11:07:54 Does that work? I rsync'd it, but hadn't got as far as trying it yet... Jan 13 11:08:19 works awesome, i just installed to a SCSI disk in about 40min Jan 13 11:08:32 lots faster than the usb/karmic installs i tried Jan 13 11:08:42 The casper improvements? Jan 13 11:08:50 no, the SCISI driver :) Jan 13 11:08:54 *SCSI Jan 13 11:09:06 Oh... I don't have a board I can use that with yet :( Jan 13 11:09:16 it boots as slow as before, i dont think JamieBennett uploaded the new casper changes yet Jan 13 11:09:35 Oh, right. Well I'll look forward to those Jan 13 11:09:49 though the install boots in about 30secs Jan 13 11:10:02 the disk throughput really changed Jan 13 11:10:29 When you say 30 secs, is that to gdm login, or to the desktop? Jan 13 11:10:48 I had 80 secs to the desktop on 20100108, booting from SD Jan 13 11:10:57 autologin to the desktop on third boot Jan 13 11:10:58 asac: Pulled firefox-3.6, and trying the benchmark now. It seems to be working better than ff3.5 Jan 13 11:11:17 hmm, hdparm disagrees with my personal feeling Jan 13 11:11:19 Timing buffered disk reads: 54 MB in 3.05 seconds = 17.71 MB/sec Jan 13 11:11:26 thats not a high throughput Jan 13 11:11:57 ogra: I'll be working on that next week but there is an initial branch for casper changes at https://code.edge.launchpad.net/~jamiebennett/casper/debconf-speedup-work Jan 13 11:12:14 not quite working yet though Jan 13 11:14:54 yeah, i would have been surprised if it had made A2 Jan 13 11:16:29 The pieces are there they just need putting together when I get time :) Jan 13 11:16:38 yeah Jan 13 11:17:27 When ogra said "it's faster" I just jumped to conclusions ;) Jan 13 11:17:34 :) Jan 13 11:22:10 chromium feels a lot smoother than FF ... i'm curious if the benchmarks will agree Jan 13 11:24:49 ogra: if i wanna to try chromium on my board, need i add a PPA, right? Jan 13 11:26:04 cooloney, see other channel ... Jan 13 11:26:25 phew, scrolling in software center is unusably slow Jan 13 11:26:47 * ogra installs banshee for the fun of seeing it crashing Jan 13 11:27:27 * JamieBennett assign's ogra the "[jamiebennett] Banshee on ARM: TODO" task ;) Jan 13 11:27:32 haha Jan 13 11:27:44 no, thanks, i had that long enough during karmic :P Jan 13 11:27:51 :D Jan 13 11:28:11 but who knows, probably it magically works now ... Jan 13 11:30:06 ogra: bug 506910 - Is that in the installed system or on the live-cd? Jan 13 11:30:08 JamieBennett: Bug 506910 on http://launchpad.net/bugs/506910 is private Jan 13 11:34:04 (if it ever finishes to install :P ) Jan 13 11:34:12 hmm, audioCD and hardwareManager instances throw exceptions ... Jan 13 11:34:14 UI comes up but then it crashes ... as it was in karmic Jan 13 11:34:45 * JamieBennett changes that TODO to DONE now then ;) Jan 13 11:37:11 JamieBennett, both Jan 13 11:37:20 it persists after install Jan 13 11:37:26 oh, funny Jan 13 11:37:36 i had my headphone plugged to the mic input Jan 13 11:37:48 that actually generates mono output Jan 13 11:38:04 ogra: OK, its to be removed from the seeds after the alpha's Jan 13 11:38:11 indeed Jan 13 11:38:31 though someone (upstream) should really look into pybootchartgui Jan 13 11:38:38 Indeed Jan 13 11:38:46 its so broken on all arches Jan 13 11:44:57 dmart, ok, i switched back to wired, wget'ing http://cdimage.ubuntu.com/ports/daily-live/20100112.2/lucid-desktop-armel+imx51.img gets me "358K/s ETA 30m 36s" seems to be fine Jan 13 11:45:24 * ogra will leave it running for a while to see if the value persists Jan 13 11:45:29 ok Jan 13 11:46:05 note that i'm running the latest kernel from the archive, not cooloney's new test kernel yet Jan 13 11:47:17 same here Jan 13 11:47:20 ok Jan 13 11:59:20 dmart: thanks Jan 13 12:01:03 ogra: did you try the new uimage script? Jan 13 12:01:05 that works Jan 13 12:01:13 or didnt you read all my bug comments ;) Jan 13 12:01:23 i will close the bug now if you dont say it doesnt work Jan 13 12:06:44 Is anyone else seeing weird window corruption since the last xorg update? Jan 13 12:07:07 My first guess was that there was a pixman bug, but pixman hasn't been rebuilt since last November Jan 13 12:09:42 dmart: Someone reported it here on beagle Jan 13 12:10:03 dmart: Someone else mentionned this was a kernel vfp state corruption for which the patch was pending a merge upstream Jan 13 12:10:44 Do you know whether there's an lp bug? I have some xwds I could attach. Jan 13 12:11:28 freenode-#ubuntu-arm-20100104.log:11:05 < ssvb> cwillu_at_work: for pixman it means that the signal handler responsible for input handling may corrupt NEON registers and as these are used for processing pixel data, it results in image artefacts which look as horizontal stripes Jan 13 12:12:05 09:00 < ssvb> lool: but I know for sure that such problem existed with problematic kernels and it resulted in a similar looking artefacts on screen Jan 13 12:12:20 dmart: 10:35 < ssvb> lool: here is a testcase for kernel bug: http://siarhei.siamashka.name/files/20100104/test-sighandler-vfp-corruption-bug.c Jan 13 12:12:54 I'm using babbage2 though... is CONFIG_NEON enabled in the kernel? Pixman should not be using NEON. Jan 13 12:13:21 ...which leads to an interesting question: how do we handling enableing NEON on babbage3 but not on babbage2.x ? Jan 13 12:14:05 dmart: that was supposed to be achieved as a kernel patch Jan 13 12:14:14 But dont think anybody worked on that Jan 13 12:14:54 dmart: do you have any first results from the benchmark yet? Jan 13 12:15:02 like a rough direction? Jan 13 12:16:01 Rough answer is that ff3.6 works and is maybe 30% faster than ff3.5 on this benchmark. Jan 13 12:16:12 But chromium is up to ~90% faster than ff3.5 Jan 13 12:16:25 ok cool Jan 13 12:16:37 (The ff3.5 used in this comparison is ARM and karmic though, not T2 and lucid) Jan 13 12:16:42 and mem consumption is sinmlarly better than 3.6? Jan 13 12:16:57 yeah Jan 13 12:17:15 anyway, looking forward to get the results :) Jan 13 12:17:19 Don't know about that; we don't measure it. Is there a way to capture the peak memory use of a process? Jan 13 12:17:22 I'll send a mail with more detail. Jan 13 12:17:29 hmm Jan 13 12:17:33 good question Jan 13 12:17:54 i would be more interseted in memory if you open like 100 tabs in both Jan 13 12:18:34 OK, I can try to do that. What figure would you use? The virtual memory load? Jan 13 12:19:47 thats a good question ... folks usually look at RES mem Jan 13 12:21:04 maybe not a real accurate figure, just understanding if either firefox or chromium make your system creep earlier would be helpful Jan 13 12:28:27 creep or thrash? Jan 13 12:32:39 depends on the load i guess ;) Jan 13 12:43:00 lool: do we know for sure that there is a signal handler using VFP/NEON, and do we know where it is? Jan 13 12:46:36 lool: Also, how do I see the IRC log? If I go to #ubuntu-arm-20100104.log:11:05 I just see an empty channel. Jan 13 12:53:08 dmart: check if the log here is better: http://irclogs.ubuntu.com/2010/01/04/ Jan 13 12:53:11 * asac lunch Jan 13 12:53:49 Better, thanks. Jan 13 12:55:55 asac, i havent tried your script yet, will doso now Jan 13 12:59:05 dmart: Probably just my tz is one hour delta Jan 13 12:59:15 lool: It may make sense that switching to another pixman resolves the corruption problem: pixman-0.14.x (karmic) doesn't have the NEON support so cannot fall victim to the neon state corruption. Jan 13 12:59:24 dmart: That's my personal log, as asac pointed out, we have irclogs.u.c Jan 13 12:59:26 #ubuntu-arm-20100104.log:10:05 Jan 13 12:59:31 I use my logs for grepping Jan 13 12:59:42 ...no, I don't see anything there either Jan 13 12:59:45 dmart: Yes, it turned out to be a kernel bug in that case Jan 13 13:00:25 dmart: http://irclogs.ubuntu.com/2010/01/04/%23ubuntu-arm.html you don't see the conversation on pixman? Jan 13 13:00:45 Sorry... yes, on irclogs.ubuntu.com, I see it. Jan 13 13:00:52 dmart: I certainly see the conversation at 10:05am in the log Jan 13 13:00:55 The other isn't a real channel, just a local file Jan 13 13:01:04 Ah Jan 13 13:01:08 the other? Jan 13 13:01:11 lool: The problem described is that the VFP/NEON regs are not saved and restored around signal handlers... but it still sounds unusual to use those features in a signal handler. Do we know where it's happening? Jan 13 13:01:14 #ubuntu-arm-20100104.log:10:05 Jan 13 13:01:17 That's my local log file Jan 13 13:01:19 whats that? Jan 13 13:01:23 yeah Jan 13 13:01:32 but why does dmart have that ;)? Jan 13 13:01:42 anyway. i am really out for lunch now Jan 13 13:01:44 dmart: Well the patch would probably tell you; let me see Jan 13 13:01:49 He doesn't: hence the confusion :) Jan 13 13:02:54 Some random userspace app must have fp code in a signal handler? if so, the kernel patch won't explain where Jan 13 13:02:58 dmart: http://www.spinics.net/lists/arm-kernel/msg67148.html Jan 13 13:03:41 dmart: Oh dunno, I guess you could grep for signal() in pixman? Jan 13 13:03:53 Or in xorg-server; I really have no idea which signal that is Jan 13 13:04:07 It could be that some signal code gets built with cflags triggering the use of this code Jan 13 13:04:13 Hmmm, maybe it would be hard to find out. Jan 13 13:04:36 Maybe there are some apps which call pixman funcs from inside signal handlers. Jan 13 13:05:14 dmart: This might be OMAP specific though Jan 13 13:05:15 http://www.spinics.net/lists/arm-kernel/msg78429.html Jan 13 13:06:37 Yes, there's two issues: VFP/NEON save-restore around signal handlers, and save-restore around pm suspend. I don't think they're OMAP-specific. Jan 13 13:07:03 asac, did you test with dmart's uInitrd already ? Jan 13 13:07:27 dmart, do you have the mkimage command handy you used to create that uInitrd ? Jan 13 13:08:31 Sadly not... but it would have been something very similar to: Jan 13 13:08:48 ogra: ónly kernel Jan 13 13:09:12 mkimage -A arm -T initrd -C none -O linux -a 0x90800000 -d initrd.gz initrd.uImg Jan 13 13:09:14 ogra: the mkimage is trivial Jan 13 13:09:25 * ogra wonders if there is dirt on his screen or asac started speaking french Jan 13 13:09:29 dmart: sure it needs the -a? Jan 13 13:09:29 Kernel would be: Jan 13 13:09:44 ogra: i have the same dirt ;) Jan 13 13:09:48 heh Jan 13 13:09:48 mkimage -A arm -T kernel -C none -O linux -a 0x90008000 -e 0x90008000 -d zImage uLinux Jan 13 13:10:07 ok, i'll try with these Jan 13 13:10:42 0x90008000 was chosen to match what the linux/arch/arm/ makefiles to for babbage, but 0x90800000 was an arbitrary choice which seems to work. Jan 13 13:10:52 yeah Jan 13 13:11:39 ogra: try the script first ;) .. then we can look at initrd Jan 13 13:11:43 argh Jan 13 13:11:46 afaiu the -a isnt really needed :) Jan 13 13:11:52 why do we use initrd.lz everywhere Jan 13 13:11:53 but if its help, we are set Jan 13 13:11:59 sigh Jan 13 13:12:05 ogra: pick it from an install Jan 13 13:12:12 there its a gzip Jan 13 13:12:13 i want the live initrd Jan 13 13:12:19 -a probably isn't needed for initrd; I couldn't remember Jan 13 13:12:27 yes Jan 13 13:12:29 just uImage Jan 13 13:12:37 ogra: unpack it ;) Jan 13 13:12:42 and pack it Jan 13 13:12:57 gzipped or non-gzipped initrd should work, but I only tried gzipped. I never use U-Boot's own compression for this (but it probably works) Jan 13 13:13:18 dmart, we now use lzma ... not gzip anymore Jan 13 13:13:31 * ogra sighs about another special case we'll have to apply to armel image Jan 13 13:13:33 s Jan 13 13:13:37 ogra: should be easy to repack Jan 13 13:13:43 asac, thats not the point Jan 13 13:13:55 what is the point? Jan 13 13:14:03 we have to maintain every special case on treh build machine in separate code Jan 13 13:14:06 *the Jan 13 13:14:07 you can repack in debian-cd ;) Jan 13 13:14:08 hmmm... well I think I just pulled an initrd.bin image from karmic. Maybe is was lzma, maybe gz? Jan 13 13:14:22 ogra: no. we can just repack when producing the mkimage ... in debian-cd Jan 13 13:14:29 asac, yes, thats the point, extra code that misses changes made for other arches Jan 13 13:14:29 thats not really special casing Jan 13 13:14:40 ogra: we run mkimage there Jan 13 13:14:43 its one more command Jan 13 13:14:45 thats not a deal Jan 13 13:14:59 if all other archs would use uboot, i would agree Jan 13 13:15:01 Um, is there a reason we can't use lzma? Jan 13 13:15:03 but that code is special cased already Jan 13 13:15:04 still more extra code Jan 13 13:15:09 persia: uboot doesnt support it Jan 13 13:15:17 asac: And that can't be fixed easily? Jan 13 13:15:18 ogra: i can write you that extra code ;) Jan 13 13:15:26 persia, i doubt anyone every added it to uboot Jan 13 13:15:27 and maintain it ;) Jan 13 13:15:44 persia: we can make that a lucid+1 project Jan 13 13:15:47 asac, its just that we try to keep the delts as small as possible Jan 13 13:15:51 *delta Jan 13 13:15:52 Linux will decompress the initrd: U-Boot doesn't need to understand it (surely?) Jan 13 13:15:57 Yes Jan 13 13:15:57 * persia thinks it's even odds adding it to uboot or the build scripts, and prefers consistency with other architectures for documentation advantages. Jan 13 13:15:58 also uboot needs to be small Jan 13 13:16:03 ogra: you miss the point Jan 13 13:16:09 the +armel is separate anyway Jan 13 13:16:16 its no maintainence overhead to modify that Jan 13 13:16:20 dmart: Good point. Jan 13 13:16:20 The code to uncompress/interpret the initrd is in the kernel for sure Jan 13 13:16:20 anyway Jan 13 13:16:21 we have no choice ;) Jan 13 13:16:24 so not worth discussing Jan 13 13:16:26 asac, no, it uses tons of existing non-arch specific scripts Jan 13 13:16:40 asac: Except lool and dmart seem to imply that it doesn't matter how it's compressed. Jan 13 13:16:48 U-Boot has its own image compression code, but it's redundant because Linux is more flexible :) Jan 13 13:16:51 if it doesnt matter i am fine Jan 13 13:16:52 and with these we just inherit changes made by the platform team Jan 13 13:17:09 ogra: Let's do that then, and just use lzma. We don't need uboot to decompress it. Jan 13 13:17:16 right, if it works i dont care, if we have to repack anything i'm unhappy Jan 13 13:17:24 OK. Does it work? Jan 13 13:17:26 It might be slower to use lzma though Jan 13 13:17:35 Worth pointing out that you may need pass -C none to mkimage to make sure U-Boot doesn't do its own decompression pass Jan 13 13:17:37 (someone with lucid-capable hardware should test) Jan 13 13:17:37 Anyway, /me goes preparing for bunch of meetings Jan 13 13:17:42 ogra: if we have to repack dont be unhappy. thats a one liner ;) Jan 13 13:17:51 in a 100 lines arch specific file Jan 13 13:17:54 anyway. i stop Jan 13 13:17:57 ttyl Jan 13 13:18:06 asac, one we have to care for, out of sync with the rest of the distro Jan 13 13:19:29 It's not worth arguing about. One or the other of you should test passing "-C none" to mkimage to verify we don't need to care. Jan 13 13:22:56 asac, boots (and dies with an oops at the end) Jan 13 13:27:11 asac: 10:34 < lool> asac: You said in #506761 that you bumped the partition size; I guess the vfat one? Looks like another bug in the uboot vfat code (was already broken with fat16 versus 32) Jan 13 13:27:25 ogra: kernel boots and oopses? What's the oops? Jan 13 13:27:25 hey guys, since versatile arch came back in lucid, can i use qemu to test versatile lucid image now? Jan 13 13:27:31 Maybe we have the wrong kernel options? Jan 13 13:27:47 cooloney: Sure Jan 13 13:27:53 Not sure we enabled the d-i arch though Jan 13 13:27:59 *subarch rather Jan 13 13:28:05 cooloney: If there's a versatile kernel, you ought be able to use it, but you're in a better position than most to tell if the versatile kernel is correct :) Jan 13 13:29:03 https://wiki.ubuntu.com/ARM/QemuNetInstall is quite out of date Jan 13 13:29:35 cooloney: however you cant use it to test *images* Jan 13 13:29:46 lool, asac, persia: I didn't play much with fat myself. It would be handy if someone added ext4 support to uboot, but I don't think there's any plan to do it yet. Jan 13 13:29:47 The images are meant to boot on this or that hardware Jan 13 13:29:56 persia: frankly, i do not know where is versatile kernel Jan 13 13:29:59 in practice, the images might be usable with special incantations though Jan 13 13:30:06 cooloney: In the versatile .deb Jan 13 13:30:10 Kernel command line: noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw rootfstype=jffs2 ip=off Jan 13 13:30:12 lool: ok, got your Jan 13 13:30:16 * ogra wonders where that comes from Jan 13 13:30:23 its not in printenv Jan 13 13:31:01 That explains the oops, at least. Jan 13 13:31:07 ogra: that command line should be in the UBOOT code Jan 13 13:32:05 lool: do you know the URL of the versatile .deb? Jan 13 13:32:24 cooloney: https://launchpad.net/ubuntu/lucid/armel/linux-image-2.6.32-10-versatile/2.6.32-10.14 Jan 13 13:32:49 Ah I was searching in main Jan 13 13:32:57 lool: thx, a lot. Jan 13 13:34:19 I cant find it on ports, weird Jan 13 13:35:23 lool: no problem, thx Jan 13 13:35:37 http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux/linux-image-2.6.32-10-versatile_2.6.32-10.14_armel.deb Jan 13 13:35:40 Stupid proxy Jan 13 13:38:03 hmm, kernel doesnt find the ramdisk Jan 13 13:39:37 Does the kernel have lzma support? Jan 13 13:39:49 its the one from the live image Jan 13 13:39:51 so yes Jan 13 13:42:17 RAMDISK: Couldn't find valid RAM disk image starting at 0. Jan 13 13:42:19 GRR Jan 13 13:42:37 What's your bootm command? Jan 13 13:42:46 bootm 0x90007fc0 0x907fffc0 Jan 13 13:42:54 i just copied yours from the bug for now Jan 13 13:43:23 Did you supply -a to mkimage for the initrd image? I'm wondering whether U-Boot is using the load address parameter to tell linux where the initrd is. Jan 13 13:43:41 i did Jan 13 13:43:56 mkimage -A arm -T initrd -C none -O linux -a 0x90800000 -d ../initrd.lz ../uInitrd.lz Jan 13 13:44:04 i'll try with -a 0x0 Jan 13 13:44:09 Hmmm, not that then. Can you send me your kernel log? Jan 13 13:44:44 lool: yes. its a vfat issue. i will check the code if i find time Jan 13 13:44:54 ogra: -T ramdisk Jan 13 13:45:39 cooloney: why is our vmlinuz so big? Jan 13 13:46:32 RAMDISK: Couldn't find valid RAM disk image starting at 0. Jan 13 13:46:34 sniff Jan 13 13:46:54 did you pass initrd=0x.....,12M to kernel? Jan 13 13:47:04 nope Jan 13 13:47:12 i shouldnt need to Jan 13 13:47:26 No, U-boot puts that info in the tagged list Jan 13 13:47:44 Can you stick your kernel log in pastebin, ogra? I have vague memories of similar problems Jan 13 13:47:48 its just that that is used everywhere on in u-boot docs Jan 13 13:48:03 which i found odd too i have to admin Jan 13 13:48:03 dmart, you mean the serial output ? Jan 13 13:48:04 admit Jan 13 13:48:14 ogra: if possible Jan 13 13:48:26 * asac gets more coffee Jan 13 13:48:28 http://paste.ubuntu.com/356054/ Jan 13 13:48:44 ogra: thanks Jan 13 13:49:25 ogra: Jan 13 13:49:30 yep Jan 13 13:49:32 Trying to unpack rootfs image as initramfs... rootfs image is not initramfs (junk in compressed archive); looks like an initrd Jan 13 13:49:55 I guess that's wrong? lzma support missing (or something else?) Jan 13 13:50:15 thats weird Jan 13 13:50:19 oh, wait ! Jan 13 13:51:05 * ogra checks asacs script again Jan 13 13:51:12 my script? Jan 13 13:51:16 the kernel boots ;) Jan 13 13:51:22 my options to it Jan 13 13:51:32 no, its definately the right kernel Jan 13 13:51:33 ok Jan 13 13:53:56 * asac remembers that this was the stage where his bbg3 died ;) Jan 13 13:55:38 hmm, -C lzma is accepted, but doesnt fix it Jan 13 13:55:49 i think it should be -C none Jan 13 13:55:54 i AGREE Jan 13 13:55:55 anyway Jan 13 13:55:57 (I agree) Jan 13 13:55:59 thats what i used before Jan 13 13:56:10 asac, do we have a call now ? Jan 13 13:56:15 or is that an IRC meeting Jan 13 13:56:29 ogra: i will ping you ... have to call him first to tell him that we do a conference now ;) Jan 13 13:56:34 * ogra needs to know if he needs to steal the phone :) Jan 13 13:56:35 as he isnt online atm Jan 13 13:56:39 so stay tuned Jan 13 13:56:42 ok Jan 13 14:05:56 ogra: Could you merge the two rootstock branches I proposed for merging? Jan 13 14:06:14 They fix lucid support or running under lucid with default args, and would allow for less forks of the script Jan 13 14:06:18 lool, will do before ending my day, whgy dont you have direct commit access ? Jan 13 14:06:57 I might, let me check Jan 13 14:07:37 ogra: Trunk is ~ogra/project-rootstock/trunk Jan 13 14:07:52 ah, crap, i'll found a team Jan 13 14:16:01 asac: sorry, just back from a meeting, Jan 13 14:16:19 asac: are you asking about the size of vmlinuz? Jan 13 14:32:08 cooloney: yes Jan 13 15:07:06 asac: you guys are thinking the vmlinuz is too big? compare to karmic imx51 kernl? Jan 13 15:12:24 asac: has https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9.1/+bug/490792 already been fixed? Isn't that the same fix I tested a while back? Jan 13 15:12:26 Launchpad bug 490792 in xulrunner "ARM/Thumb interworking support missing from nanojit" [Unknown,Fix released] Jan 13 15:33:54 plars: firefox-3.5 is still SIGILL'ing in lucid, for reasons we don't fully understand yet... so maybe the problem wasn't fully fixed Jan 13 15:35:07 Has anyone been able to install from 20100112.2 with manual partitioning? I'm having problems: see https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/506971 and https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/507012 Jan 13 15:35:10 Launchpad bug 506971 in ubiquity "Partitions detection is wrong using manual partitioning" [Undecided,New] Jan 13 15:35:41 (Come on ubot4, second link... https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/507012) Jan 13 15:35:43 Launchpad bug 507012 in ubiquity "Attempt to create new partitions silently fails in manual partitioning" [Undecided,New] Jan 13 15:35:58 dmart: according to iso tracker, ogra was able to get through it Jan 13 15:37:13 I'm trying to reserve space to transfer the boot images to the installation medium. This is more convenient to use, and has worked in the past... but maybe it's confusing ubiquity Jan 13 15:40:11 dmart: I'm using automatic partitioning on this test right now, will try with manual later Jan 13 15:42:18 FYI, I create a 32MiB non-FS data partition (DA) at the start of the installation medium to put the boot images in. This can't be done through ubiquity, but the partition is displayed correctly after ubiquity has queried the device. Jan 13 15:43:25 dmart, just as a side note, ubot4 can also understand shorthand, such as Bug #507012 and bug #506971 Jan 13 15:43:26 Launchpad bug 507012 in ubiquity "Attempt to create new partitions silently fails in manual partitioning" [Undecided,New] https://launchpad.net/bugs/507012 Jan 13 15:43:27 Launchpad bug 506971 in ubiquity "Partitions detection is wrong using manual partitioning" [Undecided,New] https://launchpad.net/bugs/506971 Jan 13 15:43:49 persia: useful tip, thanks Jan 13 15:45:46 also, seeing an error with /usr/lib/cups/backend/scsi as soon as it comes up, but apport can't seem to locate the package (generated file maybe?) Jan 13 15:49:30 I also think that CONFIG_NEON=y is causing me problems on babbage2 (we have no babbage3 at present) Jan 13 15:49:37 I get unexplained full-system lockups Jan 13 15:52:46 dmart: lockups when doing what? Jan 13 15:53:48 cooloney: sorry. the problem is that uboot take a few second to load the vmllinuz from SD Jan 13 15:53:54 There's no pattern that I can see. Usually, when I'm running nothing in particular (ubiquity just now) or when the board is unattended for a while. Jan 13 15:54:09 cooloney: the fsl bin kernel is like 30% smaller ... Jan 13 15:54:11 dmart, is there instability in general? Jan 13 15:54:30 cooloney: so everything we can safe there would be great. Jan 13 15:54:35 dmart, I remember reading somewhere that there were known issues with NEON on Babbage 1, and possibly also on the babbage 2 Jan 13 15:54:39 plars: thats fixed in firefox-3.6 Jan 13 15:54:55 It feels like just a low-frequency random problem, but I didn't see anything similar with karmic. This is the only kind of instability I see (apart for some app crashes of the sort which other people see too and which is to be expected for an alpha) Jan 13 15:55:07 plars: there are two issues with firefox. the one we fixed, and that one from above. Jan 13 15:55:14 the one above is only fixed in firefox 3.6 Jan 13 15:55:28 plars: firefox-3.6/xulrunner 1.9.2 are now available here: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+packages Jan 13 15:55:31 asac: ok, figured it might be something like that, thanks Jan 13 15:55:31 will soon be in archive Jan 13 15:56:20 NCommander: you are right: babbage 3 is fixed, but all earlier versions have this problem. We must address this config difference it in the kernel somehow since there are expected to be some products based on the babbage-2 SoC Jan 13 15:56:44 Note: I don't know if the lockups are connected with CONFIG_NEON, that's just my current guess. Jan 13 15:56:50 dmart, but won't apps that have NEON just fault the board then? Jan 13 15:57:58 Unfortunately, it's not that simple. Only certain memory accesses cause problems, and even then I think it depends on other factors. I remember running a NEON-enabled ffmpeg on babbage-1: some runs it would work OK; on other identical runs the board might freeze Jan 13 15:59:22 dmart, uuuuuuuuuuuuuuuuugggggggggggghhhhhhhhhhh :-/ Jan 13 15:59:37 This is why CONFIG_NEON was =n Jan 13 15:59:54 dmart, but disabling CONFIG_NEON doesn't prevent NEON instructions from actually being executed, does it? Jan 13 15:59:57 ...but for babbage-3 we really do want it =y Jan 13 16:00:19 dmart, there are a couple of ways we could handle it if need be. Jan 13 16:00:51 NCommander: CONFIG_NEON=n will turn some NEON instructions into SIGILLs, but unfortunately not all of them because there is some overlap between the VFP and NEON opcode spaces. Jan 13 16:01:07 NCommander: chromium neon code definitly triggers SIGILL ... i was told because of CONFIG_NEON=n Jan 13 16:01:34 Could be... I've probably only run it with CONFIG_NEON=y. It works well (apart from the slight board instability) Jan 13 16:01:37 dmart, so even flipping CONFIG_NEON won't solve the issue Jan 13 16:02:09 If Chromium is dependent on NEON and cannot adapt at run-time, it's a bug: not all target platforms have NEON anyway. Jan 13 16:02:31 i pointed you to the bug ;) Jan 13 16:02:42 they dont see that worth the effort Jan 13 16:03:17 but i guess they would be open for well maintainable patches Jan 13 16:03:27 Can you point me to the bug again? I seem to have lost it. Jan 13 16:03:40 dmart: maybe coming up with a good list of devices that will have this well help Jan 13 16:03:45 one moment Jan 13 16:04:05 http://code.google.com/p/chromium/issues/detail?id=30991 Jan 13 16:04:06 dmart: ^ Jan 13 16:04:10 check comment 4 Jan 13 16:15:32 cooloney: so we have CONFIG_NEON=y now? Jan 13 16:26:10 asac: yeah, it is turned on Jan 13 16:26:51 dmart: so should we or shouldnt we have that on? or do we first want to confirm that bbg2 breakage is really due to that? Jan 13 16:27:27 I'll discuss with cooloney a bit first Jan 13 16:39:37 plars, dmart, i didnt do manual partitioning, but a rezize+side-by-side install to keep my build chroot on the dosk (we dont have an option for that on the isotracker, manual just seems closest) Jan 13 16:39:40 *disk Jan 13 16:40:36 ok Jan 13 16:40:59 ogra: did you see this cups backend bug also? Jan 13 16:41:20 seems to be a stack smashing thing Jan 13 16:41:22 nope Jan 13 16:41:34 ogra: odd, comes up every boot for me Jan 13 16:41:52 i only saw a pybootchartgui apport msg and a "scsi died" apport one Jan 13 16:42:07 i wasnt able to reproduce the latter to get apport data though Jan 13 16:42:10 ogra: right, it's the scsi one Jan 13 16:42:16 doing it now Jan 13 16:42:20 thanks Jan 13 16:42:25 i only saw it once Jan 13 16:42:32 and it didnt return Jan 13 16:44:04 GrueMaster, plars, (or whoever tests the current imx images) can you make sure the logout menu is populated ? Jan 13 16:44:10 ouch... /me considers going out for lunch while lp logs in Jan 13 16:44:14 that was one we did the respin for Jan 13 16:44:41 plars, dont try to use FF with LP from the babbage ... something is wonky there Jan 13 16:44:43 grr, ff just died Jan 13 16:44:49 yeah, I see now Jan 13 16:45:00 Sure, but it may be a little while. I just triggered my image pull, and I have a dental appointment in 1 hour. Jan 13 16:45:04 * ogra immediately switched to chromium :) Jan 13 16:45:06 ogra: it is not populated, but I'm on 20100112.2, not on 13 Jan 13 16:45:24 right, 12.2 had that Jan 13 16:45:29 13 is supposed to fix it Jan 13 16:45:35 also, the power control menu appears to be separated from the indicator applet session now Jan 13 16:45:45 we had a bunch of outdated packages on 12.2 Jan 13 16:45:46 ogra: iso tracker still points to 12.2 as the one to test Jan 13 16:46:03 i just got a mail notification for 13, weird Jan 13 16:46:05 oh Jan 13 16:46:10 no, it updated now Jan 13 16:46:11 crap Jan 13 16:46:13 * plars starts over Jan 13 16:46:24 it was at 12.2 when I started this morning :) Jan 13 16:46:51 yeah, 13 just finished Jan 13 16:47:01 got the mail 20min ago it seems Jan 13 16:47:22 * ogra was busy with uboot, so didnt notice it until now Jan 13 17:04:52 device-mapper: dm-raid45: initialized v0.2594b Jan 13 17:04:52 Done. Jan 13 17:04:52 Begin: Running /scripts/init-premount ... Jan 13 17:04:52 Done. Jan 13 17:04:52 Begin: Mounting root file system... ... Jan 13 17:04:53 Begin: Running /scripts/casper-premount ... Jan 13 17:04:55 Done. Jan 13 17:04:59 Done. Jan 13 17:05:01 * ogra dances madly Jan 13 17:05:03 asac, ^^^ Jan 13 17:05:05 :D Jan 13 17:05:07 aha! Jan 13 17:05:09 nice :) Jan 13 17:06:39 ogra: rock and roll. please update us Jan 13 17:06:54 mmcinfo; setenv bootargs 'console=ttymxc0,115200 boot=casper'; fatload mmc 0:2 0x90300000 uImage; fatload mmc 0:2 0x91600000 /uinitrd; bootm 0x90300000 0x91600000 Jan 13 17:07:04 thats my magic Jan 13 17:07:22 how much space do you give kernel? Jan 13 17:07:22 uinitrd created with: mkimage -A arm -T ramdisk -C none -O linux -d ../initrd.lz ../uInitrd Jan 13 17:07:35 0x1300000 Jan 13 17:07:38 yep Jan 13 17:07:47 19922944 Jan 13 17:07:49 enough i suppose :) Jan 13 17:07:53 19M? Jan 13 17:08:02 thats too much Jan 13 17:08:16 or does it need more space than the image? Jan 13 17:08:20 well, i wanted to play safe for getting it up and running Jan 13 17:08:31 not really Jan 13 17:08:32 ok. i would hope we can use 5M Jan 13 17:08:41 why ? Jan 13 17:08:47 we have plenty of RAM Jan 13 17:08:55 well. why waste Jan 13 17:08:56 I think Linux will sort out the memory layout during boot; the "hole" isn't wasted Jan 13 17:09:02 right Jan 13 17:09:04 (I think) Jan 13 17:09:10 i think youre right Jan 13 17:09:16 Anyway, the initrd should be freed after boot anyway? Jan 13 17:09:21 right Jan 13 17:09:24 2.5% is 13M Jan 13 17:09:33 for 512 Jan 13 17:09:44 ok Jan 13 17:09:48 asac, it gets moved around after boot Jan 13 17:09:50 so if its not wasted its fine Jan 13 17:10:05 but we can go with 10M if you feel better then Jan 13 17:10:07 and those numbers are just random? Jan 13 17:10:13 i doubt we'll get a 19M kernel Jan 13 17:10:23 yes, its just where uboot loads it Jan 13 17:10:34 once it gets executed it gets moved Jan 13 17:10:42 then why doesnt 0x9000800 work? Jan 13 17:11:01 whats causing the breakage with that? Jan 13 17:11:14 uboot itself copies itself into ram Jan 13 17:11:38 0x800 might be to small so the kernel might overwrite it Jan 13 17:11:48 (just guessing here) Jan 13 17:11:51 8000 Jan 13 17:11:57 but yeah Jan 13 17:13:20 8000 should actually work, the important part is that initramfs doesnt overwrite parts of the kernel Jan 13 17:13:44 i'll try with smaller values ... at least i know it works now Jan 13 17:14:16 There may be a hard-coded assumption that the kernel image is loaded to 0x90008000, but I don't know for certain Jan 13 17:14:37 i think thats what bootm has by default Jan 13 17:14:42 For the initrd it shouldn't matter, providing it doesn't overlap anything else. Jan 13 17:14:47 right Jan 13 17:15:14 * ogra tries if the second option to bootm is actually needed Jan 13 17:15:37 Probably the kernel image must still not overwrite the initramfs after decompression (I think the decompress code is pretty much the first thing to run) Jan 13 17:15:40 i think it should work with only one Jan 13 17:15:55 meh, its needed Jan 13 17:16:21 That was the conclusion I came to... U-Boot doesn't seem to magically know it after you load in initrd uimage Jan 13 17:16:41 well, it does on the sheevaplug and beagleboard Jan 13 17:16:58 so i thought it does here too Jan 13 17:17:22 Hmmm... maybe there's some magic if you pre-set something in the environment? A lot of platform-specific things seem to be done this way. Jan 13 17:17:24 0x90800000 and 0x91600000 works fine as well btw Jan 13 17:17:33 yeah Jan 13 17:17:34 cool Jan 13 17:17:40 ogra: so shall i add a feature to the -script that just copies the initrd to / ? Jan 13 17:17:50 * asac just does that Jan 13 17:17:53 i'll touch the defaults of our uboot package soon Jan 13 17:17:57 asac, yep Jan 13 17:18:47 ogra: so format doesnt matter ... just copy and use -C none? Jan 13 17:18:52 NCommander, so how do i teach our imx uboot to like .scr files ? :) Jan 13 17:18:55 and -a and -e doesnt matter either? Jan 13 17:19:01 mkimage -A arm -T ramdisk -C none -O linux -d ../initrd.lz ../uInitrd Jan 13 17:19:01 .scr? Jan 13 17:19:04 thats what i used Jan 13 17:19:12 dmart, uboot script file Jan 13 17:19:26 you can hand the environment to it from a .scr file Jan 13 17:19:28 ogra, the easiest way to test things is to take the dove bootcmd, and tailor it to the imx51 Jan 13 17:19:35 ogra: ok, so we will ship our uimages in / or /boot ... i assume we want the same defaults on live and on install Jan 13 17:19:35 makes changing the cmdline easier Jan 13 17:19:40 mkimage ... -C script ... ? It works, but I had to put all the commands one one line, separated with ; Jan 13 17:19:49 yeah Jan 13 17:20:03 dmart, with the uboot from our package ? Jan 13 17:20:05 dmart, you shouldn't hjave to do that with a script file. Jan 13 17:20:34 asac, for the live images the default is usually /casper Jan 13 17:20:45 ogra: possibly not the same one, but still derived from a recent fsl release Jan 13 17:20:47 asac, but we can change it to / Jan 13 17:21:30 ogra: right. i think for now we should at least put the boot.scr at a fixed location. we can use different ones if we really want for live vs. install Jan 13 17:21:40 or dont go for .scr in the first iteration at all Jan 13 17:21:44 NCommander: how else would I change the cmdline? Jan 13 17:21:45 asac, i guess we want a /boot formatted in vfat Jan 13 17:21:56 yes Jan 13 17:21:57 asac, so we can load from / Jan 13 17:21:58 so that would be / then Jan 13 17:21:59 right Jan 13 17:22:01 dmart, on dove? For live media, or an installed system? Jan 13 17:22:05 so we dont need a .scr for first iteration Jan 13 17:22:14 nor for second Jan 13 17:22:27 ogra: whats the second iteration? Jan 13 17:22:29 .scr is only intresting to make it easier to change the cmdline imho Jan 13 17:22:34 NCommander: Ah. I'm thinking of post-install on imx51. Jan 13 17:22:43 asac, no idea, you said first :P Jan 13 17:22:50 * ogra grins Jan 13 17:23:03 ogra: ok. i just thought you wanted it ... if you dont want i am fine - at least until we have usb support in uboot for fsl Jan 13 17:23:05 ogra, there are other benefits Jan 13 17:23:09 someting like on dove doesnt make sense Jan 13 17:23:17 right Jan 13 17:23:19 NCommander: usb doesnt work yet Jan 13 17:23:41 there will soon be other benefits :-) Jan 13 17:23:47 NCommander: where is the uboot source for dove Jan 13 17:23:48 NCommander, first target is to make uboot work like redboot ... Jan 13 17:23:53 NCommander: thats not in the archive? Jan 13 17:23:57 on top of that we can do other shiny things Jan 13 17:24:29 NCommander, oh, right, you wanted to package that long ago :) Jan 13 17:24:38 ogra, asac http://people.canonical.com/~mcasadevall/dove/Dove_UBoot_4_3_1_Full_Release_NQ.zip Jan 13 17:24:41 NCommander: if it isnt, can you make that availbable in a prominent location ? Jan 13 17:24:52 NCommander, package it :) Jan 13 17:24:56 NCommander: ok. that needs to go in the archive Jan 13 17:24:56 asac, ogra, we never were able to resolve the redistribution rights on doimage's binary Jan 13 17:25:01 oh Jan 13 17:25:05 asac, it got caught up in Marvell's legal department Jan 13 17:25:10 can you send me a mail with details? Jan 13 17:25:11 thanks Jan 13 17:25:22 NCommander, cant you just make a .bin ? Jan 13 17:25:29 ogra, ? Jan 13 17:25:31 from upstream plus patches ? Jan 13 17:25:35 ogra, can't. Jan 13 17:25:39 ogra, well, ok, I could Jan 13 17:25:40 oh, why ? Jan 13 17:25:44 But it would be fairly useless Jan 13 17:25:44 right Jan 13 17:25:52 Basically, we have the uboot source which compiles to a bin Jan 13 17:25:57 but the board won't accept a .bin by itself Jan 13 17:26:02 NCommander: please send me a short mail about the background and the current state. i want to keep this moving ... Jan 13 17:26:03 yes, i know Jan 13 17:26:16 but if you have doimage you can turn the .bin into something Jan 13 17:26:25 just a real short one with the main bullets Jan 13 17:26:43 so having the .bin in the archive would help people owning doimage Jan 13 17:27:32 it takes less than 1h to copy the debian dir out of the uboot-imx package and make the needed changes i bet Jan 13 17:27:49 to turn it into a uboot-dove package Jan 13 17:28:34 yes, thats what we should be doing as a first step Jan 13 17:28:38 right Jan 13 17:28:56 so people owning doimage could quickly recompile it with extra options they want Jan 13 17:29:07 i have it on my radar now :) Jan 13 17:29:13 good Jan 13 17:41:47 asac, pushed a README to uboot-image-script with the working set of bootcmds Jan 13 17:42:39 cool Jan 13 17:54:03 hmm, slight problem Jan 13 17:54:09 seems the NIC doesnt come up Jan 13 17:56:37 wow, thats bad Jan 13 18:03:01 ok, something to find out about tomorrow Jan 13 18:05:07 SHRIEK ! Jan 13 18:05:16 * ogra sees setenv ethaddr 00:04:9F:00:EA:D7 in the freescale docs Jan 13 18:05:48 i hope we dont have to invent random HW adresses during uboot bootup Jan 13 18:06:13 ogra: the nic doesnt come up at uboot stage? Jan 13 18:06:22 no, not at all Jan 13 18:06:38 i mean also not on the running system Jan 13 18:06:48 i cant even bring it up with ifconfig Jan 13 18:06:55 it doesnt get initialized Jan 13 18:07:02 end the setenv helps? Jan 13 18:07:22 no idea, just trying Jan 13 18:07:26 and Jan 13 18:07:30 would be odd Jan 13 18:07:35 driver loaded? Jan 13 18:07:35 ;) Jan 13 18:07:44 no, that would be normal Jan 13 18:07:54 we had similar issues in redboot at some point Jan 13 18:08:06 redboot wiping the mac in hardware? Jan 13 18:08:19 no, the nic not getting initialized Jan 13 18:08:41 if the silicon isnt powered up properly, the kernel cant fix it Jan 13 18:08:58 * ogra waits for the board to boot Jan 13 18:09:01 but how can the boot loader power up something the kernel cant? Jan 13 18:09:04 ;) Jan 13 18:09:18 it talks to the HW on a different level Jan 13 18:09:46 you mean in a different mode? Jan 13 18:10:07 on a lower level Jan 13 18:10:16 call it mode if you like :) Jan 13 18:10:37 ogra: the power control menu is populated on the live image, but not once it's installed Jan 13 18:10:42 well, setenv didnt help Jan 13 18:10:54 plars, sounds liek a bug Jan 13 18:10:55 ogra: you use ramdisk for the type of initrd? Jan 13 18:11:01 e.g. mkimage ... -T ramdisk ? Jan 13 18:11:06 or initrd? Jan 13 18:11:07 asac, yes, what else should i use ? Jan 13 18:11:08 ogra: was there a bug open for this already? Jan 13 18:11:21 asac, initrd isnt a valid keyword Jan 13 18:11:28 right Jan 13 18:11:34 i just saw you mentioned that Jan 13 18:11:38 plars, not from me, but slangasek told me about it, he might know Jan 13 18:11:45 ogra: i will use uInitrd as name is that ok with you? Jan 13 18:11:51 sure Jan 13 18:12:00 whatever works :) Jan 13 18:12:48 hmm, so i guess i'll dive into the uboot code tomorrow to find out if the right NIC driver is used Jan 13 18:12:55 thats really weird Jan 13 18:16:14 cooloney, do you use the FEC driver from freescale or amitk's hacked up version from karmic ? Jan 13 18:17:48 ogra: it is from fsl not amitk's version Jan 13 18:17:55 hmm Jan 13 18:17:57 ok Jan 13 18:17:59 ogra: any problem? Jan 13 18:18:16 well, i noticed that i dont see plug events Jan 13 18:18:27 i was hoping the new FSL version fixes that Jan 13 18:18:40 (we didnt see them in karmic either) Jan 13 18:19:02 so network-manager doesnt react if i plug/unplug the cable Jan 13 18:19:12 cooloney: fsl probably didn't add the platform device patch that we have in karmic Jan 13 18:19:19 jeremy did that patch Jan 13 18:19:33 amitk, well, that didnt add plug events, just made it appear in NM ... Jan 13 18:19:52 right Jan 13 18:19:54 i see it in NM but still have to switch it on/off manually if i unplug the wire Jan 13 18:20:24 then they haven't implemented runtime PM Jan 13 18:20:41 seems they expose a platform device at least this round Jan 13 18:21:52 ogra: cool, if we find a bug, please file a bug, and we can work on that Jan 13 18:22:41 will do Jan 13 18:25:40 hmm, i dont get why uboot doesnt have something like an fecinit command to bring the NIC up Jan 13 18:26:40 * ogra goes afk for now ... Jan 13 18:42:57 yes. i can boot into my lost karmic partition again ;) using lucid kernel/initrd Jan 13 18:43:25 under lucid my usb storage disc is broken ... so really seems to be userspace breakage Jan 13 18:45:21 thats what happens when you rice! Jan 13 18:46:00 probably ;) Jan 13 19:21:46 asac, did you check the NIC ? Jan 13 19:22:01 its probably a board specific issue that doesnt show up on all boards Jan 13 21:57:25 hi Jan 13 21:58:33 is here some Canonical developers responsible for porting ubuntu to arm architecture? Jan 13 22:06:57 I heard about support from Marvell and Freescale with the ARM port and I would like to know how Open this support is do they provide source code or docs or binary blob & nda? Jan 13 22:07:34 which company is more Open Source friendly Jan 13 22:07:52 in other words Jan 13 22:11:08 Riotta: which binary blobs? Jan 13 22:11:38 Riotta: the images we produce (that work) have no binary blobs in there atm. of course not all hardware is fully supported Jan 13 22:11:45 dunno if such exist it was a question Jan 13 22:11:59 the current images we have, are all free Jan 13 22:12:02 for both Jan 13 22:12:04 ah i see Jan 13 22:12:14 both companies are open-source friendly imo Jan 13 22:12:23 of course both have legacy issues with suppliers etc. Jan 13 22:12:28 old story etc. Jan 13 22:12:31 okay Jan 13 22:12:46 good to hear that **** ENDING LOGGING AT Thu Jan 14 02:59:57 2010