**** BEGIN LOGGING AT Wed Jun 27 02:59:58 2012
Jun 27 03:41:44 is this the right place to discuss getting an ubuntu distro for the igepv2 board?
Jun 27 03:44:32 I have an old version of karmic running on my igepv2, but I'd like to upgrade to 12.04. Can't seem to find any relevant instructions. I built the omap kernel I used for my karmic install from source and used a stock rootfs. Not sure how to get 12.04 installed.
Jun 27 03:47:37 eswenson: We used to support igepv2 out of the box (more or less), but I'm not sure how much of that has bitrotted.
Jun 27 03:47:47 eswenson: Have you tried a stock 12.04/omap image?
Jun 27 03:48:29 I haven't yet. If there is a prayer of a chance that it would work, I'll give it a whirl.
Jun 27 03:49:04 I don't have the hardware to test on, and precious few people ever ask about it, so the honest answer is "I have no idea, but maybe."
Jun 27 03:49:12 I haven't played with the igepv2 for 2 years. Is it "dead" (lost cause)? Is there are better board that is similar that *is* actively supported?
Jun 27 03:49:51 The best bang for your buck these days would be the Pandaboard (or the PandaES, which is the slightly faster and newer version of the same)
Jun 27 03:50:07 I'll check it out. Thx.
Jun 27 03:51:00 If you want an omap3 (like your igepv2) instead of omap4 (which the Panda is), the Beagleboard community seems to be much more active (and we do support those in Ubuntu, though just barely, and some of us are getting sick of how awfully slow they are)
Jun 27 03:51:22 But if you're just looking for "a decent ARM device to play with", Pandas are great.
Jun 27 03:54:18 Yes, the Pandaboard ES looks really nice. Appears to cost about $180.
Jun 27 03:56:54 infinity: beagle community is far more active as there are more people actually designing products around AM3xxx series
Jun 27 04:02:22 prp^2 are you saying that the beagle community is more active than the panda board community?
Jun 27 04:03:08 eswenson: yea it is about a 4 to 1 ration on activity
Jun 27 04:03:46 Last time i checked beagle board, the board seemed quite inferior to the igepv2 board. But I'll look again.
Jun 27 04:04:11 eswenson: panda is far more active on the professional developer scene, but beagle is far more active on the low end, small volume oem, and hobbyist marked
Jun 27 04:04:37 eswenson: igepv2 is basically a beagle, and many of the igepv2 folks share the beagle community areas
Jun 27 04:05:04 eswenson: there is only the panda , no clones such as the igepv2 for beagle
Jun 27 04:06:01 I have been looking around on the igepv2 forums/wikis and it doesn't seem very active, nor has there been much interest in ubuntu since karmic.
Jun 27 04:06:25 But I have this board (igepv2) and was hoping to bring it to life with a more current kernel/distro.
Jun 27 04:06:46 But if it's really a waste of time, then I'd be up for getting another board....
Jun 27 04:06:54 eswenson: basically what works for beagle works for igepv2
Jun 27 04:07:21 So you're saying that if I took the 12.04 port for the beagle board, I should be able to get it running on the igepv2?
Jun 27 04:07:27 eswenson: yea
Jun 27 04:07:55 Same u-boot-arm and x-loader, or are these specific to the igepv2?
Jun 27 04:08:18 http://www.elinux.org/BeagleBoard#IGEPv2
Jun 27 04:09:17 So I'd probably need additional drivers for the on-board ethernet, wifi, and bluetooth...
Jun 27 04:09:45 eswenson: probably not, most of the beagle builds have all the support for the clones as well
Jun 27 04:09:54 eswenson: igepv2 has been around for some time
Jun 27 04:10:00 iirc since aroun 2008
Jun 27 04:10:03 * prpplague checks
Jun 27 04:10:05 yeah. I bought mine in 2010.
Jun 27 04:13:15 will armhf images work on the igepv2? I thought I needed armel?
Jun 27 04:21:24 the scripts I see for building the omap kernel on elinux.org suggest that while the igepv2 is weakly supported, it is supported with no video. I'll need video. My existing (karmic-era kernel) supports video fine on the igepv2.
Jun 27 04:38:17 eswenson: thats probably long out of date
Jun 27 04:38:27 eswenson: when was the page last updated?"
Jun 27 06:25:37 Page was last modified on 12 June 2012. (http://elinux.org/BeagleBoardUbuntu)
Jun 27 09:03:32 tf101, running oneiric armel but with armhf and precise added in post-install. apt.conf has APT::Default-Release "oneiric";
Jun 27 09:03:39 When I pull in mplayer, I get: mplayer: Symbol `ff_codec_bmp_tags' has different size in shared object, consider re-linking
Jun 27 09:03:44 ...and mplayer: relocation error: mplayer: symbol __aeabi_f2ulz, version LIBAVCODEC_53 not defined in file libavcodec.so.53 with link time reference
Jun 27 09:04:07 Is it obvious to anyone which package(s) should be up/downgraded to address that?
Jun 27 09:04:23 Plan B is to just poke at the libavcodec packages and see what happens.
Jun 27 09:08:46 Ah, oops, I thought I was testing the mplayer from precise, but it was the oneiric mplayer, so no surprise it wasn't working.
Jun 27 09:14:12 Cool, works now (apt-get install mplayer/precise --no-install-recommends libavformat53/precise libavcodec53/precise libva1/precise).
Jun 27 09:44:07 Having a problem with my Pi and getting my wifi dongle Netgear N150 wna1100 to work. New to using debian, have followed instruction on net but must be missing the point somewhere.
Jun 27 09:47:24 Can see dongle when using lsusb, but can not see after have done a update and install of firmware. Think it could be my interfaces file but have no idea
Jun 27 09:48:03 you probably want to go to #debian-arm on oftc.net
Jun 27 09:48:26 thank you will do
Jun 27 13:22:22 I installed the ubuntu desktop image for the beagleboard-xM. here is the command that I typed and its output http://paste.ubuntu.com/1062526/ after that I inserted the sd card into the board and powered it up. however, I dont see any output on the monitor. I use hdmi dvi-d cable for it.
Jun 27 13:23:08 do I do something wrong?
Jun 27 13:32:54 or what do I need to do next?
Jun 27 13:35:58 it should just work, do you have a proper power supply attached ?
Jun 27 13:36:37 iirc the bone uses a lot less power than the XM, you will need some decent PSU for driving the USB hub on board
Jun 27 13:36:54 I am supplying it by a 5V, 1A adapter
Jun 27 13:37:08 not sure 1A is sufficient
Jun 27 13:37:48 user manual says 1A is minimum at some pages, on other pages 1.5A min
Jun 27 13:37:54 i know th epandaboard wont work with less then 2A
Jun 27 13:38:03 minimum, yeah
Jun 27 13:38:06 I saw youtube videos that they just supply with usb to mini usb
Jun 27 13:38:11 that means with nothing attached at all
Jun 27 13:38:37 right, but if you attach a USB keyboard and mouse the world looks different :)
Jun 27 13:38:46 :)
Jun 27 13:38:48 i can easily power my beagle C4 from mini USB
Jun 27 13:38:57 so when I have a proper power supply, it should work fine, right?
Jun 27 13:39:02 i dont think that works with my XM (though i must admit i never tried)
Jun 27 13:39:24 well, if your issue is power, then it should, yeah
Jun 27 13:39:48 so I need to wait one more day to try it :(
Jun 27 13:40:03 thank you for your help
Jun 27 13:40:04 the images are tested in a ton of different setups and i'm positive they work out of the box if there isnt any HW issue
Jun 27 13:40:29 I just wonder if there is any additional step that I need to do after booting it
Jun 27 13:40:36 in any case you should see bootloader messages on the serial port
Jun 27 13:40:58 I will have the serial cable tomorrow
Jun 27 13:41:06 great
Jun 27 13:41:33 I can not access it through the ethernet connection, right?
Jun 27 13:41:40 ??
Jun 27 13:41:42 nope
Jun 27 13:41:52 you have to pulg it into the serial port of the beagle
Jun 27 13:41:55 *plug
Jun 27 13:42:52 got it. is there any video instruction for it?
Jun 27 13:43:34 i dont think so ... and i would be surprised if you need it
Jun 27 13:43:53 the cable usually only has a serial plug on one side and an USB plug on the other
Jun 27 13:44:05 serial goes into the serial socket on the board, usb into your PC
Jun 27 13:44:28 I wanted to mean the ubuntu installation to a beagleboard
Jun 27 13:44:47 nope, no video of that either
Jun 27 13:45:31 its boots into a graphical config tool (or console config tool if you use the server image) asks for timezone, keymap, language and user data, and thats is
Jun 27 13:47:01 that was what I wondered :) so it is the reason that I can not use ssh before setting those settings, isn't it?
Jun 27 13:47:24 you can not use ssh because there is no ssh server installed by default
Jun 27 13:48:19 ah ok
Jun 27 13:48:36 so I will wait for tomorrow to proceed. thanks a lot again
Jun 27 13:50:14 do you know the reason why beagleboard links to elinux for ubuntu? http://beagleboard.org/project/ubuntu/
Jun 27 13:50:26 why not https://wiki.ubuntu.com/ARM/
Jun 27 13:50:45 I mean as a homepage
Jun 27 13:51:09 nope, no idea
Jun 27 13:51:23 ask in #beagle :)
Jun 27 13:51:30 right:) thank you
Jun 27 13:51:35 someone there likely maintains these links
Jun 27 14:02:48 marvin24, are the DRM patches being currently sent to the tegra part of fixing the graphics on tegra, and the biggest blocker yet before full support is ready?
Jun 27 14:03:21 marvin24, I know you told me before some large pieces of code are still needed for full support but I do not remember if you said exactly which
Jun 27 14:04:10 janimo: drm is only a prove of concept and not planed to upstream in the current form
Jun 27 14:04:30 on the tegra list there is a discussion on how to setup the device tree info currently
Jun 27 14:04:44 and code comes after that ...
Jun 27 14:05:02 also there is almost no power management support on mainline
Jun 27 14:05:40 marvin24, is that because overall PM framework has changes so much that the pm code in 3.1 is of no use?
Jun 27 14:05:53 3.1 and 2.6.x which works on ac100
Jun 27 14:08:11 janimo: I surely can't
Jun 27 14:08:28 if you like to care for forward porting 6000 patches, you can try
Jun 27 14:09:19 marvin24, I mean the reason for PM framework changes between 3.1 and 3.6 is why it needs a complete rewrite?
Jun 27 14:09:58 janimo: honestly, I don't know
Jun 27 14:10:13 I guess it is more lag of developers
Jun 27 14:10:18 marvin24, I saw no clear tegra mainlining roadmap ever - if there is one - so I still have no idea what is planned for when and how much effort it is
Jun 27 14:10:29 so it makes planning for packaging a bit harder :)
Jun 27 14:10:45 yes, nvidia never was very "communicative"
Jun 27 14:11:04 janimo: did you saw the post of Stephen Warren on the xorg list?
Jun 27 14:11:33 marvin24, I am not following that list, so no
Jun 27 14:11:48 link?
Jun 27 14:12:07 sorry, it was kernel summit: http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/000304.html
Jun 27 14:12:33 I think he is open for more responses
Jun 27 15:03:54 marvin24, thanks, reading now
Jun 27 16:31:48 NCommander: the current highbank installer initrd appears to be corrupt. The kernel doesn't like it and "cpio -i --to-stdout < Downloads/initrd > /dev/null" gives "cpio: premature end of file"
Jun 27 16:35:13 md5 sum is okay though...
Jun 27 16:41:52 robher: The initrd from the archive, or some homebrew thing from NCommander?
Jun 27 16:43:03 infinity: from the archive. uploaded today.
Jun 27 16:43:17 robher: zcat initrd.gz | cpio -t looked fine to me.
Jun 27 16:43:40 As did actually extracting it.
Jun 27 16:43:56 (base)adconrad@cthulhu:~/hb$ zcat initrd.gz | cpio -i
Jun 27 16:43:56 cpio: dev/console: Cannot mknod: Operation not permitted
Jun 27 16:43:56 cpio: dev/null: Cannot mknod: Operation not permitted
Jun 27 16:43:56 24314 blocks
Jun 27 16:44:03 ^-- Looks fine.
Jun 27 16:45:21 robher: 20101020ubuntu150?
Jun 27 16:48:07 infinity: Those commands work for me too. Strange...
Jun 27 16:48:41 infinity: yes, 20101020ubuntu150
Jun 27 16:50:49 infinity: seems --to-stdout doesn't work. Other initrds that work have the same message. Back to u-boot debug...
Jun 27 16:52:46 hm... is -d implicit with cpio these days?
Jun 27 17:06:32 marvin24, do you know ny tegra specific fbcon issues with 2.6.39?
Jun 27 17:19:40 nexus 7 live: https://developers.google.com/events/io/
Jun 27 18:29:46 infinity: same problem with different kernels. other initrds work with installer kernel. I can reproduce the problem within qemu as well. If I gunzip the initrd and re-gzip it, it works fine.
Jun 27 18:30:26 robher: Seriously? That's disconcerting. And a much deeper bug, then.
Jun 27 18:30:57 robher: And I'm trying to decide if I blame it on gzip or the kernel.
Jun 27 18:32:10 robher: A rebuild will probably "fix" it, but boy, I'd like to know how it's breaking in ways that gzip doesn't mind but the kernel's internal zlib routines hate.
Jun 27 18:32:34 wow
Jun 27 18:32:47 could be the convervativeness of the offset on decompression
Jun 27 18:32:59 b/c its a one-shot decompressor and it decompresses in place in ram
Jun 27 18:33:15 Sure. Could be a lot of things.
Jun 27 18:33:21 But this isn't exactly something we see often.
Jun 27 18:33:38 (In that, I've never seen it before at all, and we kinda rely on initrds for... Everything)
Jun 27 18:33:51 infinity: perhaps the kernel's gunzip doesn't like something in newer gzip? I'm on precise.
Jun 27 18:34:08 oh wait, robher are you using 3.5?
Jun 27 18:34:09 Maybe I should just switch debian-installer to producing lzma initrds by default and scream "LA LA LA".
Jun 27 18:34:22 scientes: No, he's using 3.2
Jun 27 18:34:45 ok, cause there is a bug that was created in merging otherwise good code in 3.5, for arm compressoin
Jun 27 18:34:49 Or, wait. This was highbank?
Jun 27 18:34:57 I've lost track.
Jun 27 18:35:08 The kernel log has "rootfs image is not initramfs (no cpio magic); looks like an initrd" then later...
Jun 27 18:35:08 highbank is 3.5 in quantal, yes.
Jun 27 18:35:21 well that that is probably it
Jun 27 18:35:30 the problem is that the decompression stuff declres STRING_H
Jun 27 18:35:31 But he claimed he tried the initrd with older kernels.
Jun 27 18:35:39 and prevents the real string.h loading
Jun 27 18:35:53 robher: You tried the quantal initrd with a precise kernel and got the same error?
Jun 27 18:35:54 and linking with early boot/decompression stuff
Jun 27 18:36:07 now that was already there, but some new code now actually wants to use string.h
Jun 27 18:36:25 i did some messaging on the mailinglist of the person's code that was affected, but nothing came of it
Jun 27 18:38:44 I've tried mainline 3.2 + highbank patches and see the problem.
Jun 27 18:39:22 Could the highbank patches be backporting this problematic bit that scientes speaks of?
Jun 27 18:40:06 > the recently added to arm, CONFIG_KERNEL_XZ is broken because
Jun 27 18:40:06 > arch/arm/boot/compressed/decompress.c defines _LINUX_STRING_H
Jun 27 18:40:06 > overriding used in include/linux/dynamic_debug.h:111
Jun 27 18:41:00 i didn't really research the scope, it could go beyond xz, a kernel i compiled with gzip didn't boot for me
Jun 27 18:41:11 scientes: And, despite that being an XZ patch, that breaks all compression methods?
Jun 27 18:41:23 Fun.
Jun 27 18:41:29 infinity, it was actually the debug patch that was broken
Jun 27 18:41:34 both were merged inthe same window
Jun 27 18:41:37 so both are to blame
Jun 27 18:41:42 Check.
Jun 27 18:41:42 it was a conflict that wasn't seen
Jun 27 18:42:04 Well, if this is the bug, we should report it, track it, and fix it.
Jun 27 18:42:28 robher: Is your "mainline+highbank" kernel a homebrew, or our 3.2.0 from precise-updates?
Jun 27 18:42:37 i send that to the debug person, but he didn't seem adament about fixing it, the STRING_H stuff was put there years ago, by Russel, but only now became a problem
Jun 27 18:43:33 i can only think that it was put there to try to make stuff leaner
Jun 27 18:44:02 anywas, may not be the problem, but its definitely a bug
Jun 27 18:45:24 infinity: it is not an ubuntu kernel. It's roughly what I've published on our git tree.
Jun 27 18:45:34 I did find this: I'm seeing where I have to remove CONFIG_BLK_DEV_RAM from the kernel
Jun 27 18:45:35 to get it to boot with an external initramfs image. It says the image
Jun 27 18:45:35 is not good (junk in it), but it boots. The same image boots fine
Jun 27 18:45:35 when built into the kernel using INITRAMFS_SOURCE, even with
Jun 27 18:45:35 BLK_DEV_RAM in the kernel.
Jun 27 18:46:20 from the lakml
Jun 27 18:48:53 robher: Can you check if it works with the precise 3.2.0 kernel?
Jun 27 18:49:00 robher: Just as a datapoint.
Jun 27 18:49:29 If the initramfs really doesn't load with ANY kernel, I'd be looking to blame gzip.
Jun 27 18:49:40 hello, what toolchain are you using for allwinnerA10 (it's an armv7 but the images people have built are for armv5)
Jun 27 18:50:03 deviker, all ubuntu is armv7, even the soft float armel
Jun 27 18:50:25 scientes: (sort of)
Jun 27 18:50:42 I guess I shouldn't confuse people, though.
Jun 27 18:51:03 infinity, are you referencing assembly that isn't ported?
Jun 27 18:51:18 or is certainly C compiled with differn't settings
Jun 27 18:51:21 deviker: We're not doing anything for the A10, but if someone were to do so on Ubuntu, our toolchain on armhf defaults to armv7-a.
Jun 27 18:51:42 scientes: No, I'm refering to the fact that quantal's armel toolchain is armv5t.
Jun 27 18:51:45 scientes: Shh, don't tell anyone.
Jun 27 18:51:50 oh wow
Jun 27 18:52:23 just the toolchain, or its settings?
Jun 27 18:52:59 thanks, I've to go I'll be back in a hour
Jun 27 18:53:01 cause you keep telling everyone they cant run ubuntu on their sheevaplugs or rasperri pis
Jun 27 18:53:03 scientes: The defaults in general. It's been a silent rolling rebuild that is, well, "public" (cause people can read changelogs), but not "publicised", cause we don't want people getting all excited about it, in case we decide to just drop the port instead (which we may well do)
Jun 27 18:53:55 scientes: And yeah, booting quantal/armel on a Pi would fail miserably right now, cause half the archive is still v7. ;)
Jun 27 18:54:11 scientes: Lazy organic zero-effort rebuild, for the win.
Jun 27 18:54:31 scientes: If we decide to keep armel, I'll scan the archive a month before release for remaining v7 bits in main and rebuild them.
Jun 27 18:54:38 scientes: universe won't be so lucky.
Jun 27 18:54:52 well im liking my systemd setup on my sheevaplug ;)
Jun 27 18:55:00 (with debian)
Jun 27 18:55:06 I assumed, yes. ;)
Jun 27 18:58:43 infinity: same problem with precise 3.2.0-26.41
Jun 27 18:59:03 * infinity grumps.
Jun 27 18:59:13 Of course, that still doesn't rule out the highbank sauce.
Jun 27 18:59:37 Someone should try it with an i386 kernel. :P
Jun 27 19:05:31 infinity: the first version of the highbank installer posted worked fine. That was on 3.4, but the highbank parts haven't really changed.
Jun 27 19:08:27 robher: So, there is a kernel that will load that initrd?
Jun 27 19:12:01 infinity: no, no. A previous quantal initrd for highbank worked.
Jun 27 19:12:48 robher: Oh, yeah, that's probably a less interesting datapoint.
Jun 27 19:13:13 robher: If I can find a round tuit, I'd like to know if *any* kernel can decompress the new initrd.
Jun 27 19:13:19 omap4, something not ARM at all, whatever.
Jun 27 19:13:43 If it universally explodes on everything, then it's obviously(ish) something wrong with how it's being generated.
Jun 27 19:14:06 If only highbank kernels complain about it, then there's something wonky in that patchset tickling a misbehaviour.
Jun 27 19:14:28 But, if there's something wrong with how we generate initrds, I'm frankly shocked that this is the very first one we've had that breaks.
Jun 27 19:15:18 (I suppose the other--really remote--possibility is that there was some subtle corruption when it was generated that doesn't bug gzip, but does bug the kernel, but what are the odds?)
Jun 27 19:19:59 infinity: perhaps uncompress and recompress on quantal x86 and arm and make sure the results are the same as the original. I definitely got a different size with precise, but I haven't looked at the options used when building the installer
Jun 27 19:23:01 gzip -v9f ./tmp/highbank_netboot/initrd
Jun 27 19:23:04 ^-- From the log.
Jun 27 19:23:06 Nothing special.
Jun 27 19:23:15 Though the -9 may be why your size differed.
Jun 27 19:25:44 infinity: with -9 the size is the same before and after and it doesn't work.
Jun 27 19:26:05 Curious indeed.
Jun 27 19:26:14 Cause we build all our initrds with -9
Jun 27 19:26:16 And always have.
Jun 27 19:26:18 So...
Jun 27 19:30:39 yerg, you know lzma or xz gets passed -9 too and this is hideous on ARM (since the dictionary size means the buffer required to compress is easily more than most ARM devices are capable of, let alone come with on most reference boards).
Jun 27 19:31:20 given it gets decompressed into memory anyway if it's just a compressed cpio archive, and the source data is freed up after that, does it really matter how big it is on disk?
Jun 27 19:33:55 Neko: It matters because uBoot sucks.
Jun 27 19:34:05 in what way?
Jun 27 19:34:12 u-boot doesn't decompress initrds
Jun 27 19:34:15 Neko: Smaller is much better, and I've never seen the decompression take anywhere near as long as the load.
Jun 27 19:34:20 or.. let me put that a better way. it damn well shouldn't.
Jun 27 19:34:30 Neko: No, uBoot does the load, and it's awful at it.
Jun 27 19:34:38 Neko: Hence, smaller better.
Jun 27 19:34:46 okay so you're generating uncompressed cpio initrds and then letting mkimage compress them?
Jun 27 19:35:23 Neko: No. These ones aren't mkimaged. highbank is a unique snowflake.
Jun 27 19:35:32 bootz? :)
Jun 27 19:35:58 Neko: Yeahp. Though, feeding them raw to qemu appears to exibit the same issues, to it's not the bootloade doing bad things.
Jun 27 19:36:07 that's not really unique not to want to use uimage anymore. okay.. so you just want them as small as possible. well I'd try using something other than gzip for a start.
Jun 27 19:36:50 infinity: u-boot is the snowflake. :)
Jun 27 19:36:56 kernel supports xz and xz initrds actually decompress faster than gzip ones somehow :)
Jun 27 19:37:41 Neko: Yeah, yeah. None of this is news.
Jun 27 19:37:47 even at default settings you'll get better compression out of it and a slightly faster boot. it's really a no-brainer on what to do..
Jun 27 19:37:53