| TheMuso | So... I think I tracked down why omap*/panda aren't bootable after a net install in quantal... The omap and omap4 keywords are missing from the flash-kernel-installer sub-architecture package field. | 00:50 |
|---|---|---|
| TheMuso | So the package doesn't get installed into the d-i environment when net-retriever/anna is run. | 00:50 |
| TheMuso | Now... To work out how I can test my theory without uploading. I only want to do a flash-kernel upload if I *know* that is the fix. Hrm. | 00:52 |
| infinity | TheMuso: You could tear apart the d-i initrd and make your changes to f-k-i manually. | 00:58 |
| infinity | TheMuso: Though, I'm not sure you're right in this case. f-k-i in 3.0 doesn't seem to have ANY board logic at all, it just calls flash-kernel in the target. | 01:02 |
| infinity | TheMuso: And it apparently works for other boards (like highbank and armadaxp). | 01:02 |
| TheMuso | infinity: I was thinking along those lines, but that doesn't really test whether anna will end up installing the package into d-i. | 01:02 |
| TheMuso | Looking at a syslog from a precise d-i install, flash-kernel-installer gets installed. Quantal, it doesn't. So the package doesn't even get installed into d-i for flash-kernel to be run in the first place. | 01:03 |
| infinity | TheMuso: Oh!, you're talking XB-Subarchitecture: | 01:03 |
| TheMuso | Yes. | 01:03 |
| infinity | Right, sorry, I thought you were talking board logic, like in the 2.0 f-k-i. | 01:03 |
| TheMuso | No, sorry I should probably have been slightly clearer with which package field I meant. | 01:04 |
| infinity | I'd say that the XB-Subarchitecture: change would be correct even if it doesn't fix your bug, so upload away. | 01:04 |
| TheMuso | Thats what I'm thinking too. The worst that will happen is that it doesn't work. | 01:04 |
| infinity | TheMuso: While you're there, feel free to steal https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1026780 from ogra too. :P | 01:06 |
| ubot2 | Ubuntu bug 1026780 in flash-kernel "3.0~rc.4ubuntu4 doesn't honor bootargs from /boot/boot.script anymore" [Undecided,New] | 01:06 |
| infinity | TheMuso: And welcome to ARM porting! (sucker) | 01:06 |
| TheMuso | Sure, will take care of it. :) | 01:07 |
| TheMuso | And since powerpc is not really going anywhere any more, I need another non-x86 architecture to sink my teath into. | 01:08 |
| infinity | BenC might disagree with you. | 01:09 |
| TheMuso | ...and Jason my manager got pandaboards for all desktop team members, so I want to get quantla set up. | 01:09 |
| TheMuso | Well, for desktop use. Thats all I cared about for powerpc. | 01:09 |
| TheMuso | quantal even | 01:09 |
| infinity | I think Ben's company is targetting desktop use as well as server. | 01:09 |
| TheMuso | Oh ok. | 01:09 |
| infinity | He certainly wastes a lot of time fixing FTBFS issues in desktop stuff. | 01:10 |
| infinity | So, there must be a reason for that. :P | 01:10 |
| TheMuso | True. | 01:11 |
| infinity | Or maybe he's just doing it to prove the port is healthy. | 01:11 |
| infinity | Which is fair. | 01:11 |
| TheMuso | Well I still ahve a love of non-x86 stuff. | 01:11 |
| infinity | Since every time some part of ubuntu-desktop is broken, someone screams "oh god, the port is shit, we should drop it", and I say "but, but, I run several powerpc servers, and that stuff all works fine." | 01:12 |
| infinity | If you've given up on it, though, you can send me your powerstation. ;) | 01:12 |
| TheMuso | heh | 01:13 |
| TheMuso | Dunno, I am still undecided. | 01:13 |
| infinity | I'd use mine for desktop stuff, but I've been too lazy to buy a sound card for it. | 01:14 |
| infinity | (And by 'desktop stuff', I mean I'd keep using it as a server, but also watch movies on it, hence the need for sound) | 01:14 |
| infinity | I wonder if anyone still makes decent but cheap PCI sound cards, or if I'm stuck buying some professionally overengineered whizbang thing because every new computer ships with onboard sound that's "good enough". | 01:15 |
| TheMuso | My problem is that its too noisy. | 01:16 |
| TheMuso | So I only run it when I want to do powerpc work. | 01:16 |
| infinity | It is a bit of a wind tunnel, as designed. That could be fixed. | 01:16 |
| TheMuso | I know its as designed. | 01:17 |
| infinity | Say, did you ever try out SATA drives in yours to see if the SAS controller in there was nearline SATA friendly? | 01:18 |
| infinity | I need to try that sometime, but I don't really want to buy a drive just to find out it doesn't work. | 01:18 |
| TheMuso | No, haven't tried, as I don't have any caddies suitable for mounting another drive. I could remove the existing drive, but whats the point in only having one drive when I could have more. | 01:19 |
| infinity | I bought a bunch of rails from an eBay vendor for 3 bucks a pop. | 01:19 |
| TheMuso | Are they generic drive rails? | 01:20 |
| infinity | It's a standard IBM part, and they make clones of the part. | 01:20 |
| TheMuso | Ah ok. | 01:20 |
| infinity | 13-051054 | 01:20 |
| TheMuso | Anyway as to the bug above, would the user's /boot/boot.script overwrite the flash-kernel boot script wholesale, or are we wanting to do some funky stuff to encorporate both of them? | 01:20 |
| infinity | Googling that part number should to the trick. Or eBaying it. | 01:21 |
| TheMuso | Yep. | 01:21 |
| infinity | boot.scr should be generated from a combination of flash-kernel's internal logic and the user's boot.script. Ish. | 01:21 |
| infinity | That's more or less how it worked in 2.0, IIRC. | 01:21 |
| infinity | Anyhow, I was going to fix it later (or let Oli get to it), so don't stress about it being a prerequisite for uploading your 2-word fix or anything. :P | 01:22 |
| TheMuso | Hrm ok. | 01:22 |
| infinity | I need to do some mangling in the same general area (cmdline args) to make f-k-i play nicely with d-i in the same way grub-installer does. | 01:24 |
| infinity | So, you can just pretend we never had this conversation, if you prefer. | 01:24 |
| TheMuso | I'm just looking at flash-kernel from precise to see how it handled this usecase... | 01:26 |
| infinity | Have fun with that. I think I might shower, and go remind myself what women look like. | 01:27 |
| TheMuso | Heh ok. | 01:27 |
| TheMuso | infinity: Meh I'm not going to worry about that bug, I have other things I want to do and I want to get my board up for some pulse 2.1 testing... | 01:36 |
| TheMuso | Doesn't scratch my itch. :p | 01:36 |
| === zyga-afk is now known as zyga | ||
| janimo | ogra_, TheMuso is flash-kernel now more in sync with debian than it used to? | 08:04 |
| janimo | I knew at one point they were very diverged | 08:04 |
| ogra_ | janimo, yes, we base on the latest in deabin now | 08:38 |
| ogra_ | *debian | 08:38 |
| sveinse | I don't know if this is the right channel for this: but how do you handle backport in terms for versioning? I have a natty host, which needed boost1.46. So I took the precise sources and compiled it for natty. Time goes and its time to dist-upgrade to precise. However boost refuses to upgrade as it's the same version the one I compiled for natty. What version number should boost backported... | 08:39 |
| sveinse | ...to natty have? | 08:39 |
| sveinse | Any of you guys here had any problems cross compiling x-loader with precise -4.5 compiler? Mine compiles and runs fine with natty host, compiles fine with precise host as well, but won't start | 10:37 |
| sveinse | (this is for omap3530) | 10:37 |
| ogra_ | sveinse, we usually dont cross build u-boot, we only take what linaro gives us usually, probably ask in #linaro | 10:53 |
| sveinse | ogra_, thanks. Keeping it cool by not cross compiling then :P | 10:58 |
| ogra_ | sveinse, oh, and on a sidenote we dont use x-loader anymore since precise | 11:25 |
| ogra_ | we use the upstream u-boot-spl | 11:25 |
| sveinse | ogra_: oh, and no u-boot either then I suppose | 11:29 |
| ogra_ | we use uboot but u-boot-spl instead of xloader | 11:29 |
| sveinse | why, if I may ask | 11:30 |
| ogra_ | ease of maintenance | 11:30 |
| ogra_ | u-boot-spl is maintained inside the u-boot tree | 11:30 |
| ogra_ | x-loader was always a fork with just reduced functionallity | 11:30 |
| sveinse | interesting. Technically, is u-boot and u-boot-spl compiled from the same project then? | 11:31 |
| ogra_ | yes, same source code tress | 11:32 |
| ogra_ | *tree | 11:33 |
| sveinse | nice. I'd consider using u-boot-spl just to remove the extra x-loader package... | 11:33 |
| ogra_ | well, thats what we do in ubuntu | 11:33 |
| * sveinse apt-get source u-boot | 11:34 | |
| LetoThe2nd | ogra_: i just realized canonical is actually working on MetalAsAService: https://tbe.taleo.net/NA3/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=502 | 11:35 |
| LetoThe2nd | ogra_: it offers me to build MAAS :) | 11:35 |
| ogra_ | sure, we're working on that since a year :) | 11:35 |
| ogra_ | oh, a historical day ! | 11:36 |
| LetoThe2nd | ogra_: ? | 11:36 |
| ogra_ | microsoft had negative stock numbers for the first time in its history today :) | 11:36 |
| LetoThe2nd | ah, i thought you are finally getting loud with that project :) | 11:37 |
| ogra_ | heh, it has been promoted a lot over the last half year | 11:37 |
| * LetoThe2nd didn't read about it, neither in metalhammer nor rockhard. | 11:37 | |
| ogra_ | btw, i just inspected netboot, thats never gonna work (and i wonder why it ever did) there is no partition at all on the SD | 11:38 |
| LetoThe2nd | hehe. | 11:38 |
| ogra_ | the old flash-kernel seems to have had very bad hacks to work around this | 11:38 |
| * ogra_ will try to add a partition to the images | 11:39 | |
| LetoThe2nd | sounds like a plan, then. | 11:40 |
| sveinse | rsalveti: You there? | 12:13 |
| sveinse | Do you recall bug 813018 by any chance? | 12:14 |
| ubot2 | Launchpad bug 813018 in x-loader "gcc 4.5 breaks overo in latest x-loader (1.5.1)" [Medium,Confirmed] https://launchpad.net/bugs/813018 | 12:14 |
| sveinse | I think I hit this one when changing from natty build host (w/arm-linux-gnueabi-gcc-4.5.2-8ubuntu3cross1.47) to precise build host (w/arm-linux-gnueabi-gcc-4.5.3-12ubuntu2cross1.61) | 12:17 |
| sveinse | Why did ubuntu decide on naming compilers as gcc-4.5? It creates just soo many hacks and ineffcients solutions, as very many scripts rely on $(CROSS_COMPILE)gcc (including the kernel) | 12:39 |
| ogra_ | sveinse, the default binary is always /usr/bin/gcc | 12:51 |
| ogra_ | (being a link to the gcc-4.x binary used in a release) | 12:52 |
| sveinse | ogra_: My point was directed at the nomenclature for arm-linux-gnueabi-gcc-4.x. IMHO arm-linux-gnueabi-4.x-gcc would create less friction | 13:03 |
| sveinse | well, it was a sigh, nothing more | 13:03 |
| janimo | marvin24, do you know what happens in unified tegra kernels with errata handling? Seems to me some or all are hard-configured in the build, but would need runtime detection when run on multiple possible targets | 13:32 |
| sveinse | Does arm-linux-gnueabi-gcc have --sysroot support on precise? (well technically its ld that needs to support it) It wasn't on natty. | 13:38 |
| marvin24 | janimo: there is no runtime detection for most erratas yet | 13:39 |
| marvin24 | I guess there will never be | 13:39 |
| marvin24 | you can only build kernels for a specific soc | 13:40 |
| janimo | marvin24, I guess that adds overhead or suboptimal performance to chips unaffected by some? | 13:40 |
| marvin24 | yes, I think so | 13:40 |
| marvin24 | there was a discussion about this some time ago on the arm list | 13:40 |
| janimo | but could be done by runtime patching I guess when booting up | 13:41 |
| marvin24 | if you want to get nailed, you could propose it ... | 13:42 |
| janimo | ogra_, do you also have touchpad not working on the ac100 with latest install? | 13:42 |
| janimo | marvin24, heh I was just wondering aloud, I am not even thinking on taking up such work :) | 13:42 |
| * marvin24 hints janimo to the F9 key | 13:43 | |
| ogra_ | janimo, works fine here | 13:44 |
| janimo | ah the F9 key which I keep forgetting about :) | 13:44 |
| * janimo will check ASAP | 13:44 | |
| Lopako | Hi all, I'm working with a few small ARM boards, currently focusing on the Gumstix Overo, although I'm pretty much a beginner at this level. | 21:14 |
| Lopako | I've been having a little trouble (and a lot of confusion) trying to get an Ubuntu bootable sd card up and running for the Overo, and was hoping someone here could help clear up some things | 21:15 |
| Lopako | Instructions I've found, pretty much all use the rootfs utility | 21:15 |
| Lopako | *sorry, rootstock utility | 21:15 |
| Lopako | to make the rootfs for an ubuntu distribution | 21:16 |
| Lopako | but that's deprecated now, and they recommend using Ubuntu-Core for your rootfs | 21:16 |
| Lopako | I guess my first specific question is what is the difference between the boot files (MLO, u-boot.bin, and the uImage kernel) on the hardware's site (gumstix.org), and the boot files with the same names on the ports.ubuntu.com site? | 21:19 |
| Lopako | my second concern is about the hardware specific firmware and modules: | 21:21 |
| Lopako | are they tied to the specific kernel used? | 21:21 |
| Lopako | and if so, how can I figure out the version of the kernel they need, and the version I have? | 21:22 |
| Lopako | any insight is greatly appreciated, thanks | 21:22 |
| infinity | Lopako: Since we don't provide either a kernel or a bootloader for that device, the difference between our MLO/uBoot/uImage and theirs would be that "theirs works". | 21:27 |
| infinity | Lopako: Oh, unless it's one of the OMAP3 variants. | 21:27 |
| infinity | Lopako: In which case, I'd recommend just using our -omap images and seeing if that works. | 21:28 |
| Lopako | yeah, it's an OMAP3 | 21:28 |
| infinity | Right, then. Our images might Just Work. Unless it needs drivers we don't/can't ship. | 21:28 |
| infinity | Not having the hardware myself, I can't be wildly helpful. | 21:29 |
| infinity | But have you tried just blatting our of our images to an SD and seeing what happens? | 21:29 |
| Lopako | okay ... so the "-omap images" you're talking about are the full system SD card images? (vs. just the rootfs) | 21:29 |
| Lopako | not yet, I was hoping to use a more lightweight version than the desktop image (which I used for a PandaBoard I'm also working with) | 21:30 |
| infinity | Yeah. | 21:30 |
| infinity | You could grab the server image. | 21:31 |
| Lopako | ok | 21:31 |
| infinity | It's large in size, but only because it has a package pool on it. The actual installed system is tiny. | 21:31 |
| Lopako | are all the current preinstalled images armhf? | 21:32 |
| infinity | Lopako: Yes. | 22:09 |
| infinity | Lopako: You almost certainly want armhf, unless you have some whacky obscure armel binary you just can't live without. | 22:10 |
| Lopako | mk, the armhf vs armel choice still trips me up sometimes, I must have reread wiki pages on them 10 times this week | 22:11 |
| infinity | Lopako: armhf = the new hotness | 22:12 |
| infinity | Lopako: armel = binary compatible with older stuff, but slower and unsupported in the future | 22:12 |
| Lopako | my end goal is to get software (ROS) on the Overo that's gonna have lots of dependencies which I'm worried about | 22:12 |
| Lopako | haha | 22:12 |
| Lopako | gotcha | 22:12 |
| Lopako | btw, thank you for your help, infinity | 22:12 |
| infinity | Is this software from some third-party that distributes binaries? | 22:12 |
| infinity | Cause if it's from source (or in the Ubuntu archive), armhf won't be a problem at all. | 22:13 |
| infinity | If it's from a third-party, lean on them to fix their crap, if they don't have an armhf build. :P | 22:13 |
| infinity | Cause all future ARM ports for major distros are moving to armhf. | 22:13 |
| Lopako | it's a big system of packages, most of them source, but often having system dependencies that can be tricky | 22:14 |
| Lopako | how hard is it to make that move? | 22:14 |
| infinity | Lopako: Well, not harder for armhf than armel. | 22:15 |
| infinity | Lopako: The system deps should all be there, we built the entire archive for armhf. | 22:15 |
| infinity | Lopako: And building from source is, well, the same on either. | 22:15 |
| Lopako | okay, that's good to know | 22:16 |
| Lopako | I'm interning for the company responsible for most of the core stuff, so this will be good to sell them on getting with the future =) | 22:17 |
| Lopako | Just to double-check my understanding, if there's a library I need that has an armel binary, but no armhf binary in the archives, it should be fairly simple /compatible to built the source for armhf? | 22:19 |
| infinity | Yes, but I doubt you'll find that situation. | 22:29 |
| infinity | Our archive coverage was pretty good. | 22:30 |
| infinity | Well, more to the point, you won't find anything that is buildable, but not in the archive. :P | 22:30 |
| infinity | The only reason it wouldn't be is if it failed to build. | 22:30 |
| Lopako | oo, k | 22:35 |
| Lopako | thanks | 22:35 |
| === Lopi_ is now known as Lopi | ||
| === XorA is now known as XorA|gone | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!