[00:18] heh, the write protect switch on this one (which is actually labelled as such) isn't actually wired to anything [00:18] oh, nvm [00:18] I guess that's the reader's responsibility, isn't it [00:19] that's correct.. i just found that out myself too last week.. broken sd socket on a imx31... really secure.. ;) [00:19] I never used the switch myself anyway [00:20] okay, I'm off for supper, later :) [00:20] later [01:02] venGm [01:14] GrueMaster: You may want to verify that ^^ isn't a significant string. [01:14] it isn't. [01:15] System keeps shifting focus while I am typing. It is partial password to a test system in my network. [01:16] Not even a useful account. [01:16] And hopefully one that isn't remote-accessible :) [01:18] random amusing comment in a thread about wifi troubles on a beagleboard: [01:18] "Switching to short barker preamble..." [01:18] "Well, there's your problem: everyone knows beagles are LONG barkers." [04:40] playya_: what are you doing with ubuntu on pre/milestone? === nslu2-log_ is now known as nslu2-log === XorA|fife is now known as XorA [07:51] tmzt, nothing yet. we're using OE to build our distributions [08:19] ogra_cmpc: do you have time? [08:19] ogra_cmpc: i saw this error "Uninitialized omap_chip, please fix!" in the dmesg you posted [08:27] Hey, trying to install Lucid on a BeagleBoard (i.e., an OMAP device), it gets as far as the partitioner without issue, but then cannot find the SD card, depite having booted off it (though my understanding is that only the boot loader touches it then, so that's not conclusive about the kernel finding it) [08:28] The more annoying part for me is that an identically formatted SD card worked on another BeagleBoard here with no problem. [08:32] gsnedders, which BB revision do you have? [08:33] gsnedders, and which lucid image did you try: netbook or server? [08:35] zyga: C4, I use using the image from https://wiki.ubuntu.com/ARM/BeagleNetInstall [08:36] gsnedders, strange, anything seemingly relevant in the system log? [08:36] Not that I saw [08:37] did you try _exactly_ same sd card in other devices? [08:37] perhaps something is wrong with that one card? [08:38] Oh, now I see something in dmesg, looking again, from a long time after the initial boot [08:39] it picks up the SD card, and it's size, then some line of output saying just "mmcblk0: p1" and then "retrying using single block read: [08:40] But no, I haven't tried the same SD card in other devices. It's expected I can't boot from one already with Ubuntu installed on it like that, right, as it boots from NAND? [08:40] * gsnedders should get a serial cable and try and boot another BB with that SD card [08:40] gsnedders, you can always boot from an SD card I think [08:41] gsnedders, just push the user button/reset button together [08:41] gsnedders, and try another SD card (the one that worked in other devices) [08:47] * gsnedders was unaware of that [08:48] pressing both buttons it still beats fron NAND [08:48] morning [08:49] er, hold user, press reset, release reset, wait a bit. [08:49] then release user. [08:49] ogra: ping [08:51] beats from NAND? boots. [08:52] zyga: Another SD card with Ubuntu already installed on it? [08:52] gsnedders, just put the netbook/server/netboot install image on some sd card that worked before [08:52] gsnedders, and follow DanaG's instructions on how to boot from SD [08:52] hrw, morning, how are you? [08:52] hrw, flood is getting worse [08:53] hrw, did you manage to boot your BB [08:54] Hmm, the only SD card I have that I know worked before has a full Ubuntu install on it, so that's not really an option [08:54] zyga: I even installed netbook on it. but did not rebooted to it yet [08:55] gsnedders, get some more SD cards, I know it sucks but they _are_ cheap [08:55] zyga: took me some time to make my ubuntu less free&open [08:55] gsnedders, and after you install some image you can boot from NAND and use USB storage for main filesystem [08:55] gsnedders, (so you don't have to use SD cards all the time) [08:56] hrw, are you drafting any specs? [08:56] zyga: There's plenty of SD cards around here, and using them all the time isn't actually a big problem [08:56] (even if they are slow) [08:56] zyga: cross compiler packages one now and was asked for arm toolchain one [08:58] * gsnedders wonders if we have any sort of USB storage around in the office he can use [09:00] gsnedders, thumb drive ;-) ? [09:00] zyga: thumb drive? [09:00] hrw, yeah [09:00] why so limiting... [09:01] hrw, 1) no power reqs, 2) silent, 3) could be fast enough if you have good device [09:01] grab usb-storage raid5 ;d [09:01] Ubuntu can't fit on nand. :( [09:01] * gsnedders notes that the other BB he has has just power, an SD card, and a USB network interface plugged in, and he kinda likes that minimalisim [09:02] well, initramfs can... but I don't know how to make it use the initramfs. [09:02] zyga: I think I'd still have to go out and buy one anyway :P [09:03] DanaG, you don't have to fit the whole thing in nand, having boot/kernel parts there is enough [09:05] * gsnedders concludes we must have other SD cards in the office… [09:09] Hmm, now a bunch of I/O errors trying to get at the SD card [09:11] Then trying to install onto a USB thumb drive I found it gets stuck at computing partitions [09:11] Something really weird is going on [09:13] Stuck in such a way that I can't change terminal and see what's going on [09:14] So after 3s or so of having the USB thumb drive plugged in it seems to freeze [09:15] lag, hey [09:17] ogra: I've been told to speak with you [09:17] ogra: I've just successfully compiled Ubuntu for ARM [09:18] ogra: How would I get that on the a board? [09:18] TFTP? uBoot? [09:18] compiled ubuntu for arm ? [09:19] Yeah [09:19] what do you mean by that ? [09:19] you rebuilt the archive ? [09:20] The ti-omap head [09:23] lag: you build an omap kernel, not ubuntu-on-arm :-p [09:23] *built [09:24] amitk, did he ? i'm still trying to decypher :) [09:24] amitk: Yes, with all the extra Debian stuff in [09:25] My apologies [09:25] lag: ok, so you built an omap kernel .deb (ubuntu-way of kernel building). ogra he now wants to put it on his (presumably) beagle board. [09:25] ok, so you have a rootfs, a kernel and an initrd ? [09:26] Nope, if I had those I'd know what to do with them [09:26] if its a beagle, just use the lucdi image and then replace the kernel with your package [09:26] *lucid [09:26] I have 34 .udeb files and 3 .deb files? [09:26] lag: no apologies required, it's still early in the morning :) [09:27] amitk: :) [09:27] lag, install one of the images from here https://wiki.ubuntu.com/ARM/Beagle [09:27] after that just install the linux-image deb in the new install [09:31] The Beagle board was just an example - I don't actually have one of those here [09:32] Can I test my new kernel in qemu? [09:36] there is a qemu-maemo somewhere but i dont know how well it works [09:36] (its not in ubuntu though) [10:05] ogra: hi could help to me test again? [10:05] indeed [10:07] ogra: http://people.canonical.com/~roc/kernel/omap4/ [10:07] ogra: i saw this error "Uninitialized omap_chip, please fix!" in the dmesg [10:07] you posted [10:07] oh, i missed that [10:08] it means the kernel does not think the chip is an OMAP chip [10:09] so cpu1 was not up [10:09] yeah [10:13] cooloney, hmm, looks slightly better but i get a ton of garbage on the serial console and no login prompt [10:13] i see two penguins on the LCD [10:14] which apparetnly indicates both cores were initialized [10:14] butu it seems to hang [10:14] ogra: too bad [10:14] any chance to get the dmesg? [10:15] well, its cut off due to the garbage [10:16] ok, let me check my serial port config [10:17] well, the output is fine up to a certain point [10:18] something gets enabled that trashes it [10:18] let me try to write to a log and see if i get more [10:20] ogra: thanks a lot [10:35] I have a question, but you have to promise not to laugh! =:-) [10:35] Is the omap-5912 supported by us? I'm guessing it's too LP. [10:37] thats ARM926EJ-S ? [10:37] that would be supported with 9.04 only [10:38] lag: that is ARM9, so no. We only care about ARMv7-based processors [10:38] amitk: Thanks :) [10:38] omap5912 is omap1 - arm926 [10:39] one of oldest omap devboards [10:39] A relic then [10:39] arm926 was supported in jaunty [10:39] It's the only omap board I own :( [10:39] lag: you can run Debian on it or go for Ångström [10:39] get a beagle [10:39] right, or run debian/amgstrom [10:40] I'm sure Ubuntu will give me some hardware to play with sooner or later [10:41] I would take angstrom but thats because I used it on too many devboards already [10:41] I need to run Ubuntu [10:41] The priority is the OS, not the board [10:41] :) [10:42] +1 [11:10] arm gets me all confuzzled... armv7 arm9 arm11.... sigh... [11:11] jussi: http://en.wikipedia.org/wiki/ARM_architecture [11:12] arm9 == v4 & v5 [11:13] so basically we care about cortex...? [11:13] cortex-a8/9 [11:13] ARMv7 [11:13] Bingo [11:13] :) [11:15] lag: v4, v4t, v5 I would even extend [11:15] what about those with armv6 :p [11:15] and what is i.mx51? [11:15] lilstevie: 9.10 only [11:15] jussi: armv7a [11:16] hrw: really? [11:16] jussi: i.mx5xx are cortex-a8 [11:16] hrw: Agreed [11:16] lilstevie: 10.04 is for armv7a, 9.10 was armv6 [11:16] ah :) [11:16] jussi: there are i.mx51, i.mx53, i.mx508 [11:16] hrw: Well read ;) [11:16] jussi: i.mx61/63 will be A9 [11:17] so lucid runs on imx51? [11:17] yes [11:17] yes [11:17] only on the babbage board though [11:17] ok [11:18] there are companies like pegatron that build stuff based on the imx51 design but its not quite the same which ednts up to break without images [11:18] *ends [11:18] s/without/with our/ [11:18] * ogra goes for more coffee [11:18] during uds-m guy from Freescale said that there can be i.mx51 based beagleboard-like device [11:19] the sharp is quite close to a real babbage [11:19] jussi: you could take a custom kernel and use it with lucid & maverick rootfs going forward [11:19] but uses special patches as well [11:20] hrw, probably ... but likely not in the same price segment [11:22] amitk: ahh, that sounds interesting [11:22] ogra: yep [11:23] jussi: today's hardware does not usually require specific packages to boot (other then kernel) [11:23] the babbage is actually not far away from what the XM offers in functionallity, on board sockets etc [11:23] but its $750 [11:27] hrw: what exactly do you mean by that? [11:28] a bootloader ? [11:28] are normal packages apart from the kerneal portable across arm arches? [11:29] jussi: yes, they are as long as they are not machine specific [11:29] everything we provide in lucid will work on all v7 CPUS [11:29] jussi: think: opengl support or HW accelerated audio/video codecs [11:29] hrw: how do we tell what is machine specific? [11:29] jussi: or gpio/i2c/regs related debug tools [11:30] jussi, everything that needs HW accel [11:30] What about HW FP? [11:30] jussi: s3c_gpio tool does not work on non-samsung devices. but thats just example rather not present in ubuntu [11:30] ogra: ahh, that makes sense. [11:30] (or HW debug tools) [11:30] gsnedders: you mean VFP? [11:31] hrw: yeah [11:31] thats handled by the kernel [11:31] libc hooks into a common API [11:32] gsnedders: so far I did not heard about armv7a without vfp. marvell has a line with different vfp then other cortex-a8 but I do not know how much it affects userspace [11:32] a lot :) we had massive probs in the past with the dove ports [11:33] but they usually pointed at HW issues that were resolved in a HW update [11:33] its what you get if you dont stick 100% to the specs :) [11:34] ah.. right Dove was marvell [11:34] dove/armada is an awesome platform but has its specialities :) === rsalveti_ is now known as rsalveti === JamieBen1ett is now known as JamieBennett === sumitsemwal is now known as sumitsemwal|back === sumitsemwal|back is now known as sumitsemwal [14:00] ehlo! [14:00] Does Ubuntu 10.04 run on a C4 beagle board? [14:00] i.e. TI OMAP3 [14:01] jeremiah: yes [14:01] w00t [14:01] Can you point me to an image or ISO I can burn to a flash card? [14:01] since day one: pick your poison http://elinux.org/BeagleBoardUbuntu or https://wiki.ubuntu.com/ARM/Beagle both have images.. [14:02] fantastic [14:02] thanks! === jmcgee|gone is now known as jmcgee === plars-away is now known as plars [17:03] have a nice rest of day === hrw is now known as hrw|gone [17:10] have a nice day! === sumitsemwal is now known as sumitsemwal|gone [17:23] grmbl [17:23] why does x-loader always use u-boot headers in a hardcoded mannaer [17:23] io.h -> ../../../u-boot/include/asm/io.h [17:23] hmpf [17:24] thaat will be a big quilt patch === JaMa|GoNe is now known as JaMa === rgreening_ is now known as rgreening [22:29] rcn-ee, you said rootstock on beagle was faster? [22:30] 5 hours later I'm still watching "setting up " [22:40] cwillu_at_work, just wait for https://blueprints.edge.launchpad.net/ubuntu/+spec/preinstalled-sd-card-images-for-omap to be implemented and you wont have to worry anymore ;) [22:41] ogra, that won't help me in the slightest [22:41] why ? [22:41] I'm actually making my own images [22:41] so having a bare minimal ubuntu image wouldnt help you ? [22:41] nope [22:42] how do you build your ubuntu images atm ? [22:42] note how rootstock works :) [22:42] i know how it works, i wrote it :) [22:42] okay, so how does having the bare minimal install help me when I need pieces removed from it and lots of other pieces added to it? :p [22:42] you remove pieces from a bare debootstrap ? [22:43] wow [22:43] it makes me feel special :p [22:43] you are special then :) [22:43] I'm also using a btrfs root [22:44] hmm [22:44] i was always pondering to add a minbase option to rootstock that makes it use the minbase install of debootstrap [22:44] would that help you ? [22:44] I just hack up rootstock to serve me [22:44] I should compare mine and your current to see if there's anything useful to push back [22:44] its a lot smaller but really misses functionallity due to that omission [22:44] yeah [22:45] I've got a bit of a module system, which is really just a lightweight dpkg [22:45] maverick is open, let in the crack :) [22:45] note that there are chances that ubuntu might default to btrfs with maverick [22:46] (sadly depending on grub support) [22:46] well, grub is one requirement [22:46] it's not the only one [22:46] right [22:46] there's _lots_ of oops left [22:46] but the biggest one i heard [22:46] not really; the required headers are already available under an appropriate licence [22:46] from the ubuntu foundation team side at least [22:47] for grub2 ? [22:47] some of it would have to be reworked, but that's not a huge deal [22:47] yes [22:47] i think there is some integration work left [22:47] in any case it was heavily discussed at UDS [22:47] I haven't heard cmason weigh in yet, but there's a few people who have a negative opinion of ubuntu in the btrfs dev community [22:47] and the intrest is very high [22:48] perhaps some devs should start hanging out in #btrfs, and announce themselves as such :) [22:48] yeah, not my headdache though ... the foundation team will do the most of the work as well as the decision of the default ... i'll just follow that decision in my little arm world :) [22:49] :) [22:49] though i'D love to see us switch [22:49] me too, but I think 10.10 is premature [22:49] might be ... we'll see what they decide [22:49] although there's lots of patches flying around right now, if they land and things get much better, then maybe [22:50] I'm talking from the upstream perspective [22:50] remember that that was also one of the requirements :) [22:50] well, we have some QA force out there at least :) [22:50] ("upstream needs to be happy about this" [22:50] lots and lots of testers [22:51] I'm going to tar up a copy of my rootstock infrastructure if you want to take a look [22:51] indeed upstream needs to be happy but what better can you get than having millions of users that help improving your code :) [22:51] that would be great [22:51] well... [22:51] i wont get to much rootstock work before end of next week though ... [22:51] millions of users is worse than useless if you already know you're not ready for mainstream [22:52] indeed [22:52] if you are though ... [22:52] I'm just thinking I can give you a tour of what I have, just to see if there's anything worth grabbing [22:52] module system sounds definately intresting [22:55] basically it's a separate dpkg; moving files in before vm/native, kicking off scripts and installing debs once in vm/native, and then running some post jobs after, when actually writing the tarball to an sd card, so that you can have a single root tarball, and finish up setting the hostname, installing ssh keys, etc when you're actually writing it out [22:56] separate dpkg ? [22:56] you mean you copy in .debs and install them ? [22:56] part of my use is so that when I write an image to go to a customer's site, I can set up the keys for it to log into our monitoring system, and at the same time notify the monitoring system of the new target, print out some paperwork, and so forth [22:56] no, well yes, well no. [22:56] heh [22:57] a module can include a deb which will be installed, but most don't [22:57] so just scripts [22:57] that sounds overall definately intresting [22:57] I use it to install a hacked up pixman deb to help with some performance issues, for instance [22:58] set up specific users + environment [22:58] really, it's nothing that dpkg shouldn't be able to do, but yet I find it convenient to be able to perform jobs outside of the image [22:58] you could do that with the --script option already [22:58] well, kinda [22:59] i guess you're not alone with that requirement [22:59] the idea is that you keep related stuff together, even though the pieces for a given module need to be performed at different times [22:59] not that i would need it but i see how it is useful, so a tarball would indeed make sense [23:00] right ... i was thinking about stealing the plugin system i wrote for ltsp, it does something similar ... each plugin has several stages (pre-install, install, after-install) where you can add different script snippets [23:00] yep [23:00] but its very complex [23:01] and i didnt want to make rootstock to hard to understand for novice users [23:01] do you have a standard tool to write out an image? [23:01] its its strenght currently that everyone can easily understand it [23:01] i.e., my mkcard ties into this [23:02] no, because i dont want to clash with the actual image building tools we have in ubuntu [23:02] rootstock was never meant to be an image builder, something writing images should just wrap around it [23:03] sadly someone noticed that i create qemu images on the go and sent a patch :P [23:03] the initial purpose was never to write to SD or to create disk images though ... but i'm bad at saying no if someone sends good code ;) [23:05] so if you have any good code that ties in with the std ubuntu tools (parted for example instead of fdisk/sfdisk etc) i'D happily merge it [23:06] but effectively i still think writing to disk should be done by a wrapper [23:07] in any case a tarball would be good if it saves you work to modify it everytime the upstream code changes [23:10] grrr [23:10] what was the last thing I said? [23:10] netsplit fun :) [23:11] i.e., my mkcard ties into this [23:11] and then i sadi a lot :) [23:11] *said [23:11] I missed everything you said after mkcard, and you missed everything I said :) [23:11] pasted you a PW [23:11] err [23:11] PM [23:11] I went onto a tangent about update-initramfs being interesting, but being structured inverted from how I would do it [23:12] likewise :) [23:12] heh [23:13] why not actually tie in with initramfs tools ? [23:13] for the reasons I mentioned :) [23:13] seems logical to me if you want to use any kind of raid [23:13] I hate how I have to "find | grep btrfs" if I want to tell what jobs actually exist and where they are [23:14] well, in the case of initramfs you only have two scripts usually [23:14] the hook and the actual script [23:14] the hook puts binaries you wil use in place, the script executes the, [23:14] *them [23:15] yes, but there's 11 subfolders in /scripts/ where your file could be hiding [23:15] i find that very simple once you understand how it works [23:15] absolutely, but it's not convenient [23:15] indeed because there are several stages in the boot [23:15] you don't understand my point :) [23:15] and several ways of booting (local/network etc) [23:15] I'm not saying that you don't need those hooks [23:16] I'm saying that the directory structure is inverted [23:16] I want to have a modules.d/btrfs/ folder with script names that match the hook I want [23:17] it's ungodly annoying to never be able to do a simple "ls" to see what's what :) [23:17] well, you could rework intiramfs tools, heve it that way and work with links [23:17] pretty much [23:17] make a proposal :) we might change it [23:17] did you catch the part where this is basically how my module system works already :) [23:18] its a valid concern that might simplify life for everyone [23:18] yes === kblin_ is now known as kblin [23:19] well, roll a tarball, that definately sounds intresting :) [23:19] okay; I'll send you something over the weekend; I have a site visit tomorrow that's probably going to be a long night tonight and a long day tomorrow :p [23:20] no hurry [23:20] i wont get to rootstock work before end of next week anyway [23:21] incidentally, a nice thing about knowing how to write the images is that you can punt alot of the work out to the first boot transparently, if for example qemu decides to not work with lucid's userspace :p [23:21] indeed [23:21] i wish we would find that darn bug [23:22] i also wish i could do without a VM at all [23:22] it wouls already be possible if ubuntus desktop and netbook metapackages wouldnt pull in mono :/ [23:22] hard to, while any package could contain a binary which it calls in a post-install script [23:23] no prob at all in a chrooted env [23:23] hmm? [23:23] the first stage of rootstock operates completely in a chroot [23:23] ten times faster than a VM [23:23] yes, but that's what debootstrap does already, no? [23:23] i only use the VM to actually install packages [23:24] its qemu-user in a binfmt handler that enables that [23:24] okay, but that's still a vm, no? [23:24] nope [23:24] syscall translation [23:24] as i said 10x faster [23:25] install qemu-arm-static and try out qemu-debootstrap --arch armel [23:25] I'm missing something [23:25] and that doesn't suffer the same fate under lucid? [23:25] right [23:25] it has other probs though [23:26] hmm [23:26] such as? [23:26] your /proc in a chroot comes from the host [23:26] which is x86 ... [23:26] (or whatever) [23:27] packages like mono that have a builting garbage collector that operates on /proc/self explode for example [23:27] *builtin [23:28] i'm planning to play a bit with LXC if i find the time during maverick development ... to see if that could help [23:28] if you can fake certain parts of /proc we might not need VMs anymore [23:29] it's not a complete solution, unfortunately, based on the discussion at UDS. We'd still need to fake /proc [23:29] back... cwillu_at_work i hope you did run it on a beagle with an sd card... using fast sata drives with usb converters... [23:29] and operatre nearly at host speed for 80% of the stuff you do [23:29] the gzip routine also kills it when it's working on a 1gig folder.. [23:29] persia, so you should finally sit down with lifeless and finish that fuse thingie :) [23:30] sorry [23:30] ice was falling from the sky [23:30] ice into rum and coke. .;) [23:30] lifeless isn't going to do it. We almost got StevenK to do it, but there was an interruption. [23:30] bah and then he wandered off to new challenges [23:31] which surely occupy him [23:31]