[03:41] <eswenson> is this the right place to discuss getting an ubuntu distro for the igepv2 board?
[03:44] <eswenson> 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.
[03:47] <infinity> eswenson: We used to support igepv2 out of the box (more or less), but I'm not sure how much of that has bitrotted.
[03:47] <infinity> eswenson: Have you tried a stock 12.04/omap image?
[03:48] <eswenson> I haven't yet.  If there is a prayer of a chance that it would work, I'll give it a whirl.
[03:49] <infinity> 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."
[03:49] <eswenson> 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?
[03:49] <infinity> 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)
[03:50] <eswenson> I'll check it out.  Thx.
[03:51] <infinity> 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)
[03:51] <infinity> But if you're just looking for "a decent ARM device to play with", Pandas are great.
[03:54] <eswenson> Yes, the Pandaboard ES looks really nice.  Appears to cost about $180.
[03:56] <prp^2> infinity: beagle community is far more active as there are more people actually designing products around AM3xxx series
[04:02] <eswenson> prp^2 are you saying that the beagle community is more active than the panda board community?
[04:03] <prp^2> eswenson: yea it is about a 4 to 1 ration on activity
[04:03] <eswenson> Last time i checked beagle board, the board seemed quite inferior to the igepv2 board.  But I'll look again.
[04:04] <prpplague> 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
[04:04] <prpplague> eswenson: igepv2 is basically a beagle, and many of the igepv2 folks share the beagle community areas
[04:05] <prpplague> eswenson: there is only the panda , no clones such as the igepv2 for beagle
[04:06] <eswenson> 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.
[04:06] <eswenson> But I  have this board (igepv2) and was hoping to bring it to life with a more current kernel/distro.
[04:06] <eswenson> But if it's really a waste of time, then I'd be up for getting another board....
[04:06] <prpplague> eswenson: basically what works for beagle works for igepv2
[04:07] <eswenson> 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?
[04:07] <prpplague> eswenson: yea
[04:07] <eswenson> Same u-boot-arm and x-loader, or are these specific to the igepv2?
[04:08] <prpplague> http://www.elinux.org/BeagleBoard#IGEPv2
[04:09] <eswenson> So I'd probably need additional drivers for the on-board ethernet, wifi, and bluetooth...
[04:09] <prpplague> eswenson: probably not, most of the beagle builds have all the support for the clones as well
[04:09] <prpplague> eswenson: igepv2 has been around for some time
[04:10] <prpplague> iirc since aroun 2008
[04:10]  * prpplague checks
[04:10] <eswenson> yeah.  I bought mine in 2010.
[04:13] <eswenson> will armhf images work on the igepv2?  I thought I needed armel?
[04:21] <eswenson> 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.
[04:38] <prpplague> eswenson: thats probably long out of date
[04:38] <prpplague> eswenson: when was the page last updated?"
[06:25] <eswenson> Page was last modified on 12 June 2012.  (http://elinux.org/BeagleBoardUbuntu)
[09:03] <twb> tf101, running oneiric armel but with armhf and precise added in post-install.  apt.conf has APT::Default-Release "oneiric";
[09:03] <twb> When I pull in mplayer, I get: mplayer: Symbol `ff_codec_bmp_tags' has different size in shared object, consider re-linking
[09:03] <twb> ...and mplayer: relocation error: mplayer: symbol __aeabi_f2ulz, version LIBAVCODEC_53 not defined in file libavcodec.so.53 with link time reference
[09:04] <twb> Is it obvious to anyone which package(s) should be up/downgraded to address that?
[09:04] <twb> Plan B is to just poke at the libavcodec packages and see what happens.
[09:08] <twb> Ah, oops, I thought I was testing the mplayer from precise, but it was the oneiric mplayer, so no surprise it wasn't working.
[09:14] <twb> Cool, works now (apt-get install mplayer/precise --no-install-recommends libavformat53/precise libavcodec53/precise libva1/precise).
[09:44] <Orb> 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.
[09:47] <Orb> 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
[09:48] <ogra_> you probably want to go to #debian-arm on oftc.net
[09:48] <Orb> thank you will do
[13:22] <angs> 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.
[13:23] <angs> do I do something wrong?
[13:32] <angs> or what do I need to do next?
[13:35] <ogra_> it should just work, do you have a proper power supply attached ?
[13:36] <ogra_> iirc the bone uses a lot less power than the XM, you will need some decent PSU for driving the USB hub on board
[13:36] <angs> I am supplying it by a 5V, 1A adapter
[13:37] <ogra_> not sure 1A is sufficient
[13:37] <angs> user manual says 1A is minimum at some pages, on other pages 1.5A min
[13:37] <ogra_> i know  th epandaboard wont work with less then 2A
[13:38] <ogra_> minimum, yeah
[13:38] <angs> I saw youtube videos that they just supply with usb to mini usb
[13:38] <ogra_> that means with nothing attached at all
[13:38] <ogra_> right, but if you attach a USB keyboard and mouse the world looks different :)
[13:38] <angs> :)
[13:38] <ogra_> i can easily power my beagle C4 from mini USB
[13:38] <angs> so when I have a proper power supply, it should work fine, right?
[13:39] <ogra_> i dont think that works with my XM (though i must admit i never tried)
[13:39] <ogra_> well, if your issue is power, then it should, yeah
[13:39] <angs> so I need to wait one more day to try it :(
[13:40] <angs> thank you for your help
[13:40] <ogra_> 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
[13:40] <angs> I just wonder if there is any additional step that I need to do after booting it
[13:40] <ogra_> in any case you should see bootloader messages on the serial port
[13:40] <angs> I will have the serial cable tomorrow
[13:41] <ogra_> great
[13:41] <angs> I can not access it through the ethernet connection, right?
[13:41] <ogra_> ??
[13:41] <ogra_> nope
[13:41] <ogra_> you have to pulg it into the serial port of the beagle
[13:41] <ogra_> *plug
[13:42] <angs> got it. is there any video instruction for it?
[13:43] <ogra_> i dont think so ... and i would be surprised if you need it
[13:43] <ogra_> the cable usually only has a serial plug on one side and an USB plug on the other
[13:44] <ogra_> serial goes into the serial socket on the board, usb into your PC
[13:44] <angs> I wanted to mean the ubuntu installation to a beagleboard
[13:44] <ogra_> nope, no video of that either
[13:45] <ogra_> 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
[13:47] <angs> that was what I wondered :) so it is the reason that I can not use ssh before setting those settings, isn't it?
[13:47] <ogra_> you can not use ssh because there is no ssh server installed by default
[13:48] <angs> ah ok
[13:48] <angs> so I will wait for tomorrow to proceed. thanks a lot again
[13:50] <angs> do you know the reason why beagleboard links to elinux for ubuntu? http://beagleboard.org/project/ubuntu/
[13:50] <angs> why not https://wiki.ubuntu.com/ARM/
[13:50] <angs> I mean as a homepage
[13:51] <ogra_> nope, no idea
[13:51] <ogra_> ask in #beagle :)
[13:51] <angs> right:) thank you
[13:51] <ogra_> someone there likely maintains these links
[14:02] <janimo> 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?
[14:03] <janimo> 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
[14:04] <marvin24> janimo: drm is only a prove of concept and not planed to upstream in the current form
[14:04] <marvin24> on the tegra list there is a discussion on how to setup the device tree info currently
[14:04] <marvin24> and code comes after that ...
[14:05] <marvin24> also there is almost no power management support on mainline
[14:05] <janimo> marvin24, is that because overall PM framework has changes so much that the pm code in 3.1 is of no use?
[14:05] <janimo> 3.1 and 2.6.x which works on ac100
[14:08] <marvin24> janimo: I surely can't
[14:08] <marvin24> if you like to care for forward porting 6000 patches, you can try
[14:09] <janimo> marvin24, I mean the reason for PM framework changes between 3.1 and 3.6 is why it needs a complete rewrite?
[14:09] <marvin24> janimo: honestly, I don't know
[14:10] <marvin24> I guess it is more lag of developers
[14:10] <janimo> 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
[14:10] <janimo> so it makes planning for packaging a bit harder :)
[14:10] <marvin24> yes, nvidia never was very "communicative"
[14:11] <marvin24> janimo: did you saw the post of Stephen Warren on the xorg list?
[14:11] <janimo> marvin24, I am not following that list, so no
[14:11] <janimo> link?
[14:12] <marvin24> sorry, it was kernel summit: http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/000304.html
[14:12] <marvin24> I think he is open for more responses
[15:03] <janimo> marvin24, thanks, reading now
[16:31] <robher> 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"
[16:35] <robher> md5 sum is okay though...
[16:41] <infinity> robher: The initrd from the archive, or some homebrew thing from NCommander?
[16:43] <robher> infinity: from the archive. uploaded today.
[16:43] <infinity> robher: zcat initrd.gz | cpio -t looked fine to me.
[16:43] <infinity> As did actually extracting it.
[16:43] <infinity> (base)adconrad@cthulhu:~/hb$ zcat initrd.gz | cpio -i
[16:43] <infinity> cpio: dev/console: Cannot mknod: Operation not permitted
[16:43] <infinity> cpio: dev/null: Cannot mknod: Operation not permitted
[16:43] <infinity> 24314 blocks
[16:44] <infinity> ^-- Looks fine.
[16:45] <infinity> robher: 20101020ubuntu150?
[16:48] <robher> infinity: Those commands work for me too. Strange...
[16:48] <robher> infinity: yes, 20101020ubuntu150
[16:50] <robher> infinity: seems --to-stdout doesn't work. Other initrds that work have the same message. Back to u-boot debug...
[16:52] <RoyK> hm... is -d implicit with cpio these days?
[17:06] <janimo> marvin24, do you know ny tegra specific fbcon issues with 2.6.39?
[17:19] <gildean> nexus 7 live: https://developers.google.com/events/io/
[18:29] <robher> 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.
[18:30] <infinity> robher: Seriously?  That's disconcerting.  And a much deeper bug, then.
[18:30] <infinity> robher: And I'm trying to decide if I blame it on gzip or the kernel.
[18:32] <infinity> 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.
[18:32] <scientes> wow
[18:32] <scientes> could be the convervativeness of the offset on decompression
[18:32] <scientes> b/c its a one-shot decompressor and it decompresses in place in ram
[18:33] <infinity> Sure.  Could be a lot of things.
[18:33] <infinity> But this isn't exactly something we see often.
[18:33] <infinity> (In that, I've never seen it before at all, and we kinda rely on initrds for... Everything)
[18:33] <robher> infinity: perhaps the kernel's gunzip doesn't like something in newer gzip? I'm on precise.
[18:34] <scientes> oh wait, robher are you using 3.5?
[18:34] <infinity> Maybe I should just switch debian-installer to producing lzma initrds by default and scream "LA LA LA".
[18:34] <infinity> scientes: No, he's using 3.2
[18:34] <scientes> ok, cause there is a bug that was created in merging otherwise good code in 3.5, for arm compressoin
[18:34] <infinity> Or, wait.  This was highbank?
[18:34] <infinity> I've lost track.
[18:35] <robher> The kernel log has "rootfs image is not initramfs (no cpio magic); looks like an initrd" then later...
[18:35] <infinity> highbank is 3.5 in quantal, yes.
[18:35] <scientes> well that that is probably it
[18:35] <scientes> the problem is that the decompression stuff declres STRING_H
[18:35] <infinity> But he claimed he tried the initrd with older kernels.
[18:35] <scientes> and prevents the real string.h loading
[18:35] <infinity> robher: You tried the quantal initrd with a precise kernel and got the same error?
[18:35] <scientes> and linking with early boot/decompression stuff
[18:36] <scientes> now that was already there, but some new code now actually wants to use string.h
[18:36] <scientes> i did some messaging on the mailinglist of the person's code that was affected, but nothing came of it
[18:38] <robher> I've tried mainline 3.2 + highbank patches and see the problem.
[18:39] <infinity> Could the highbank patches be backporting this problematic bit that scientes speaks of?
[18:40] <scientes> > the recently added to arm, CONFIG_KERNEL_XZ is broken because
[18:40] <scientes> > arch/arm/boot/compressed/decompress.c defines _LINUX_STRING_H
[18:40] <scientes> > overriding <linux/string.h> used in include/linux/dynamic_debug.h:111
[18:41] <scientes> i didn't really research the scope, it could go beyond xz, a kernel i compiled with gzip didn't boot for me
[18:41] <infinity> scientes: And, despite that being an XZ patch, that breaks all compression methods?
[18:41] <infinity> Fun.
[18:41] <scientes> infinity, it was actually the debug patch that was broken
[18:41] <scientes> both were merged inthe same window
[18:41] <scientes> so both are to blame
[18:41] <scientes> it was a conflict that wasn't seen
[18:41] <infinity> Check.
[18:42] <infinity> Well, if this is the bug, we should report it, track it, and fix it.
[18:42] <infinity> robher: Is your "mainline+highbank" kernel a homebrew, or our 3.2.0 from precise-updates?
[18:42] <scientes> 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
[18:43] <scientes> i can only think that it was put there to try to make stuff leaner
[18:44] <scientes> anywas, may not be the problem, but its definitely a bug
[18:45] <robher> infinity: it is not an ubuntu kernel. It's roughly what I've published on our git tree.
[18:45] <robher> I did find this: I'm seeing where I have to remove CONFIG_BLK_DEV_RAM from the kernel
[18:45] <robher> to get it to boot with an external initramfs image. It says the image
[18:45] <robher> is not good (junk in it), but it boots.  The same image boots fine
[18:45] <robher> when built into the kernel using INITRAMFS_SOURCE, even with
[18:45] <robher> BLK_DEV_RAM in the kernel.
[18:46] <robher> from the lakml
[18:48] <infinity> robher: Can you check if it works with the precise 3.2.0 kernel?
[18:49] <infinity> robher: Just as a datapoint.
[18:49] <infinity> If the initramfs really doesn't load with ANY kernel, I'd be looking to blame gzip.
[18:49] <deviker> hello, what toolchain are you using for allwinnerA10 (it's an armv7 but the images people have built are for armv5)
[18:50] <scientes> deviker, all ubuntu is armv7, even the soft float armel
[18:50] <infinity> scientes: (sort of)
[18:50] <infinity> I guess I shouldn't confuse people, though.
[18:51] <scientes> infinity, are you referencing assembly that isn't ported?
[18:51] <scientes> or is certainly C compiled with differn't settings
[18:51] <infinity> 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.
[18:51] <infinity> scientes: No, I'm refering to the fact that quantal's armel toolchain is armv5t.
[18:51] <infinity> scientes: Shh, don't tell anyone.
[18:51] <scientes> oh wow
[18:52] <scientes> just the toolchain, or its settings?
[18:52] <deviker> thanks, I've to go I'll be back in a hour
[18:53] <scientes> cause you keep telling everyone they cant run ubuntu on their sheevaplugs or rasperri pis
[18:53] <infinity> 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)
[18:53] <infinity> scientes: And yeah, booting quantal/armel on a Pi would fail miserably right now, cause half the archive is still v7. ;)
[18:54] <infinity> scientes: Lazy organic zero-effort rebuild, for the win.
[18:54] <infinity> 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.
[18:54] <infinity> scientes: universe won't be so lucky.
[18:54] <scientes> well im liking my systemd setup on my sheevaplug ;)
[18:55] <scientes> (with debian)
[18:55] <infinity> I assumed, yes. ;)
[18:58] <robher> infinity: same problem with precise 3.2.0-26.41
[18:59]  * infinity grumps.
[18:59] <infinity> Of course, that still doesn't rule out the highbank sauce.
[18:59] <infinity> Someone should try it with an i386 kernel. :P
[19:05] <robher> infinity: the first version of the highbank installer posted worked fine. That was on 3.4, but the highbank parts haven't really changed.
[19:08] <infinity> robher: So, there is a kernel that will load that initrd?
[19:12] <robher> infinity: no, no. A previous quantal initrd for highbank worked.
[19:12] <infinity> robher: Oh, yeah, that's probably a less interesting datapoint.
[19:13] <infinity> robher: If I can find a round tuit, I'd like to know if *any* kernel can decompress the new initrd.
[19:13] <infinity> omap4, something not ARM at all, whatever.
[19:13] <infinity> If it universally explodes on everything, then it's obviously(ish) something wrong with how it's being generated.
[19:14] <infinity> If only highbank kernels complain about it, then there's something wonky in that patchset tickling a misbehaviour.
[19:14] <infinity> 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.
[19:15] <infinity> (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?)
[19:19] <robher> 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
[19:23] <infinity> gzip -v9f ./tmp/highbank_netboot/initrd
[19:23] <infinity> ^-- From the log.
[19:23] <infinity> Nothing special.
[19:23] <infinity> Though the -9 may be why your size differed.
[19:25] <robher> infinity: with -9 the size is the same before and after and it doesn't work.
[19:26] <infinity> Curious indeed.
[19:26] <infinity> Cause we build all our initrds with -9
[19:26] <infinity> And always have.
[19:26] <infinity> So...
[19:30] <Neko> 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).
[19:31] <Neko> 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?
[19:33] <infinity> Neko: It matters because uBoot sucks.
[19:34] <Neko> in what way?
[19:34] <Neko> u-boot doesn't decompress initrds
[19:34] <infinity> Neko: Smaller is much better, and I've never seen the decompression take anywhere near as long as the load.
[19:34] <Neko> or.. let me put that a better way. it damn well shouldn't.
[19:34] <infinity> Neko: No, uBoot does the load, and it's awful at it.
[19:34] <infinity> Neko: Hence, smaller better.
[19:34] <Neko> okay so you're generating uncompressed cpio initrds and then letting mkimage compress them?
[19:35] <infinity> Neko: No.  These ones aren't mkimaged.  highbank is a unique snowflake.
[19:35] <Neko> bootz? :)
[19:35] <infinity> Neko: Yeahp.  Though, feeding them raw to qemu appears to exibit the same issues, to it's not the bootloade doing bad things.
[19:36] <Neko> 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.
[19:36] <robher> infinity: u-boot is the snowflake. :)
[19:36] <Neko> kernel supports xz and xz initrds actually decompress faster than gzip ones somehow :)
[19:37] <infinity> Neko: Yeah, yeah.  None of this is news.
[19:37] <Neko> 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..
[19:37] <Neko> so xz initrd doesn't work either, or?
[19:38] <infinity> Neko: And moving our initrds to a newer compression method is something to look into, but hardly addresses this current issue, just sidesteps it, possibly.
[19:38] <Neko> what is the issue, just a random borkage?
[19:38] <infinity> Neko: The issue is the kernel refusing to load this particular initrd, full stop.
[19:38] <infinity> Neko: Talking about how to build it differently doesn't in any way change that the kernel doesn't like this one. :P
[19:38] <Neko> oh shit, we saw that a bunch of times on efika and 3.2/3.4/3.5 kernels..
[19:39] <Neko> at some point it just magically solved itself
[19:39] <Neko> I think we bumped a kernel version and redid our config..
[19:39] <infinity> That's comforting.
[19:40] <Neko> well, I wish you all the luck in the world, but we spent 2 weeks looking for the problem and once we decided 3.2 was too old, I think 3.4 it didsappeared and we saw a random occurance somewhere. it may be due to decompressing overitself or maybe some really highly esoteric cache problem.
[19:40] <infinity> Given that gzip -9 is still our default for initramfs-tools-generated initrds too, we can't just let this bug float out there and hope it only happens sometimes.
[19:40] <infinity> Creating unbootable systems on upgrades is, well, bad.
[19:40] <Neko> the problem is it's most likely some u-boot weirdness.
[19:41] <infinity> robher: Can you file a bug against "linux" (I kinda want to blame the kernel for now, until we have further data) and try to summarize this IRC backscroll mess a bit?
[19:41] <Neko> the kernel works fine no matter what we do right now.. I don't think we found a config item that changed anything, or at least, nothing changed that would make a bit of difference regarding boot. we added a few new drivers and removed the old implementations but they were thoroughly checked
[19:42] <Neko> does u-boot invalidate the caches over the kernel and ramdisk area as it puts them there, or before boot?
[19:42] <infinity> robher: However we fix and/or workaround this, we need it fixed before highbank hardware starts landing in the hands of "real people", cause "rebuild your initrd 4 times and do a magic dance, and it'll work sometimes" isn't quite enterprise-ready. ;)
[19:42] <Neko> for uimage it can know the sizes involved but for a zimage and raw initrd I wonder how it'd know what to invalidate
[19:43] <infinity> Neko: Yeah, I'm not sure what crazy uBoot does here.
[19:44] <Neko> sometimes just turning off the L2 cache completely before getting to Linux isn't the solution as it doesn't always go back to memory since it's in L1.. but Linux does give things a kick, there can still be some stale data in L1, plus god knows how many SCU and L2 errata on everyone's A9 implementations these days
[19:44] <Neko> did you enable all the arm errata in the kernel just in case? :)
[19:45] <robher> infinity: I'll file the bug. It's already in the hands of real people. I was just trying to figure out why a customer was getting the can't find kernel modules error message in the installer. But I never got there...
[19:45] <infinity> robher: Oh, we already have "real customers" installing precise on highbank despite the lack of installer?
[19:45] <infinity> robher: Or bleeding edge folks using quantal?
[19:46] <robher> Neko: L2 and L1 data caches are off in u-boot.
[19:46] <infinity> robher: Either way, fun.  Please file the bug, subscribe me (adconrad), and we'll see if we can find some sane resolution to this before we "officially" support highbank in 12.04.1
[19:48] <robher> infinity: we'd rather have them using precise and we ship systems with it, but you don't have the installer published yet. So for the ones that want to do installs, quantal is their only choice ATM.
[19:50] <infinity> robher: We should make sure we get the installer bits in precise-proposed ASAP, then.
[19:50] <NCommander> robher: precise highbank is dep-wait a kernel SRU at the moment
[19:50] <infinity> NCommander: One in the PPA, or one in proposed?
[19:51] <NCommander> infinity: in the PPA. The previous upload added highbank but forgot the udebs
[19:51] <infinity> NCommander: Oh, whoops.
[19:51] <NCommander> so the fix for that had to wait for the next SRU cycle; can't upload d-i without it since it wants udebs
[19:52] <infinity> NCommander: Right, well, I was going to backport some armadaxp and highbank d-i stuff to precise-proposed and then sit on it until it was ready to be uploaded.
[19:52] <infinity> NCommander: But are all the ducks in a row WRT flash-kernel and such?
[19:52] <NCommander> infinity: yeah, I'm sitting on it right now, though I haven't uploaded to proposed
[19:53] <NCommander> (guess it wouldn't actually interfere with anything so I could just "do it")
[19:53] <infinity> NCommander: Please do, so we can review in small chunks instead of one massive vomit of SRU.
[19:53] <NCommander> infinity: will try to get everything uploaded by EOD then
[19:58] <Neko> robher, turning them on might make it load faster :)
[20:04] <robher> infinity: this might be some brokenness in bootz cmd. Putting the initrd in an uInitrd works.
[20:05] <infinity> robher: That's doubly disconcerting.
[20:05] <infinity> robher: Also, I thought you said that feeding it raw to qemu also failed?
[20:05] <infinity> robher: Which would rule out uboot/bootz.
[20:06] <infinity> robher: Unless the highbank qemu actually starts by feeding the kernel/initrd arguments to uboot. :)
[20:06] <infinity> (I haven't played with it)
[20:13] <infinity> 14:12 <apw> when i was doign highbank config fixes we had a thing where the initramfs would fail decompression
[20:13] <infinity> 14:12 <apw> but if you then hit ^d it was all in there
[20:13] <infinity> 14:12 <apw> and it was caused by the length of the initrd being somehow out of sync with what was loaded
[20:14] <infinity> 14:12 <apw> the conjecture was the loader was rounding down the size and not loading enough blocks
[20:14] <apw> there was something a
[20:14] <apw> about the boot loader needing to be told the exact size or something
[20:15] <apw> rbasak i think you were involved and may be able to use the right words
[20:16] <infinity> apw: The problem is that if someone was hacking around this with boot.scr magic in flash-kernel, it will do exactly 0 good for people loading the kernel/initrd raw.
[20:16] <infinity> rbasak: ^
[20:16] <apw> right
[21:05] <robher> infinity: it could be related to that previous issue, but the work-arounds for it didn't help this time. Avoiding u-boot copying the initrd worked before. But like all mysterious problems that disappear or are fixed in unexplained ways, they always come back
[22:12] <rbasak> robher, infinity, apw: the workaround I used that worked was to manually increase the size of the initrd provided to the bootz command to round up to the next page. This was without robher's fix. That worked for some reason.
[22:20] <robher> rbasak, infinity: Looks like u-boot is overlapping its initrd copying with its stack.
[22:27] <infinity> rbasak: You mean increase the size that you tell u-boot, or pad the initrd.gz file with zeroes past an arbitrary boundary?
[22:27] <infinity> rbasak: Cause we could certainly incorporate the latter as a hack in the d-i builds, if it works.
[22:28] <infinity> robher: That sounds unpleasant.
[22:29] <infinity> robher: On the one hand, "yay, not my bug", on the other hand, if there's anything we can facilitate as a reliability workaround, let us know.
[22:30] <robher> sp start    = 0x1FF00F60  and  ramdisk load end = 0x1ff006c3
[22:31] <infinity> That doesn't look overlapped to me, unless 6 suddenly became larger than F when I wasn't looking.
[22:32] <robher> evidently the CONFIG_STACKSIZE value is no longer used and setting it to 128K is pointless
[22:32] <robher> stacks grow down
[22:32] <infinity> Ahh.  And it's larger than f60-6c3, I take it?
[22:34] <infinity> Anyhow.  Back to work.
[22:35] <infinity> robher: Happy bug hunting.  But yes, unless you're confident that you can push fixed firmware to everyone (which would be nice), if you can come up with some hackish workaround that makes it DTRT despite the bug, let me know.
[22:36] <robher> I'm guessing so at this point. But the copy aligns the start of the initrd to 4K and so you have a variable amount of space between the end and the stack which is why it is sometimes okay.
[22:39] <robher> setenv initrd_high 0xffffffff will prevent the copy and fix it. I think you have this in the boot.scr, so it will only be an issue for pxe boots. All the systems now can be updated, so getting updates out should not be a problem.
[22:48] <robher> infinity: this could affect any ARM board and may be same problem seen on efika boards
[22:50] <Neko> I thought of that but I couldn't prove it at all
[22:51] <Neko> the difference is we weren't copying any of the images around, u-boot dumped them where we told them, and that was well, well away from the stack
[22:52] <Neko> so, sp start = top of stack, growing down into memory?
[22:52] <robher> yes
[22:53] <Neko> if I fatload an initrd into ram and bootz it, it won't relocate it as u-boot can't relocate it based on any info. for a uimage that's different but a ramdisk has a load address of 0. it should leave it where you fatloaded it to
[22:53] <Neko> are you saying on bootm or bootz it's copying the ramdisk out of the way of the kernel or some shit?
[22:54] <Neko> I may have to go see the u-boot guys about this.. but before that, I'll buy a nice new hammer, one with a rubber handle so when the blood really starts to flow.....
[22:54] <infinity> robher: Yeah, setenv obviously doesn't help for either PXE or people booting "raw" from the uboot CLI (unless they know the trick).
[22:55] <Neko> just removing that copy will reduce boot time, if your caches are disabled then a memcpy of a 10MB ramdisk will take some time.. not as long as loading it from an SD card, but appreciable nontheless.
[22:55] <infinity> robher: But if getting firmware updates out seems reasonable, I'll just happily forget we had this conversation.
[22:55] <Neko> infinity, initrd_high seems like a stupid hack to me. we set it on our development u-boot in the environment.
[22:55] <Neko> is this documented somewhere?
[22:55] <robher> what conversation...
[22:56] <Neko> we're gonna update efikamx uboot to align our old boards with DT and get the FSL dev boards acting the same way for development and unify with our new products.... I don't think I'd want this stuff getting into production releases
[22:56] <robher> There is a CONFIG flag that does the same thing and I can set it in the default environment.
[22:56] <Neko> wiki page at denx, or on an ubuntu bug properly investigated?
[22:58] <robher> Neko, just like u-boot relocates itself to the end of memory, it wants to do that for the initrd and fdt. The flag is documented in the README and there is also fdt_high.
[23:00] <robher> Neko: can I borrow the hammer when you're done with it? ;)
[23:03] <rbasak> infinity: I was increasing the size that I told u-boot on the bootz command. No padding with zeroes. The kernel did complain, but it carries on anyway, and since the valid part was uncompressed, there wasn't a problem
[23:03] <rbasak> If it's stack memory overlap I'm not sure why that worked though
[23:04] <rbasak> Unless stack is being miscalculated and dependent on the initrd size?
[23:04] <rbasak> But if it grows down, that makes no sense
[23:04] <rbasak> (to me)
[23:04] <rbasak> Anyway, it sounds like robher has worked out the problem
[23:07] <robher> rbasak: the amount of stack size all depends on the initrd size % 4K. So if you are slightly over 4K, that will leave more stack space untouched. This may explain why uImages were not working either.
[23:09] <rbasak> So how come the stack is placed right next to the initrd, anyway? :)
[23:10] <robher> because u-boot is stupid
[23:11] <robher> at least everything will be better with uefi.
[23:13] <Neko> I found the docs, and the code itself is obtuse to say the least
[23:13] <Neko> they're saying your kernel needs to support "zero copy ramdisk" to make initrd_high=0xffffffff work but that doesn't make any sense.. what system is there on this planet that doesn't support a "zero copy ramdisk"?
[23:15] <Neko> kernel piggy decompresser extracts out of the way of it's compressed code.. and out of the way of any ramdisk loaded too. ramdisk gets extracted afterwards some way into boot time based on it's format.. if it's compressed it always gets moved but the kernel always knows where it is
[23:15] <Neko> the address you load the ramdisk to is basically irrelevant, I can't imagine why u-boot would copy it around at all
[23:18] <Neko> the way we're loading internally here is start-of-mem+128kb = where boot.scr goes, start-of-mem+172kb = uImage, +10mb = dt + 10mb+64kb = initrd... in a system with 512MB or 1GB RAM even with a huge initrd, there's 450MB+ available above that. u-boot's stack starts from near top-of-mem and works down, so why incur the possibility that the stack can overwrite your stuff? linux uses memory from bottom up, that's why you keep everything low and stack
[23:18] <Neko>  high so you don't LOAD over your stack. Copying is redundant
[23:19] <Neko> also why would a 128kb uboot stack copy over a moved ramdisk, at the point uboot is moving ramdisks how can it possibly use that much stack anyway?
[23:19] <Neko> even a 4kb stack
[23:20]  * Neko goes to buy some hammer polish
[23:20] <lilstevie> lol
[23:21] <Neko> I can't complain too much because our OpenFirmware implementation couldn't load more than a 14MB initrd because it kept all it's stuff within 32MB since it could not tell at the time it determined the stack location, how much ram you actually had..
[23:21] <Neko> but that's a restriction of systems with a dynamic amount of memory where 32MB is *normal*. that's just not true for these systems.
[23:21] <Neko> is this for situations where u-boot has no clue what the memory size is when it loads?
[23:22] <Neko> because that would make some sense... not a lot, but some. I mean why couldn't it just put the stack at the low 128kb+space for page tables and cause a massive fuss if you used more than the amount of stack allocated. surely u-boot has some canary crap to make sure of this :(
[23:23] <Neko> hell on mx51 etc. why not keep running u-boot out of iram, and put the stack in iram?
[23:24] <Neko> I think I might cry :(
[23:28] <lilstevie> Neko: running the stack out of iram makes sense really
[23:29] <lilstevie> depending how much there is of course
[23:32] <Neko> 128k in mx51, 256k in mx53, 272kb in theory in mx6. actually loading u-boot in there makes no sense since the average u-boot size is 240kb.
[23:32] <Neko> but by the time u-boot loads due to the imx boot process, memory size is well known
[23:32] <Neko> so it can go in ram. but still.. fucksake.
[23:33] <Neko> I wish someone would document this with pictures that said "u-boot will go here, and your stack needs to go here, and this range is a decent range of addresses to put your files" and hopefully automatically generate such stuff as to not have to guess a load address or relocate anything ever again
[23:34]  * Neko is wondering why u-boot doesn't build if you turn off zlib and gzip support even though it never uses it