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