**** 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 so xz initrd doesn't work either, or? Jun 27 19:38:08 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. Jun 27 19:38:19 what is the issue, just a random borkage? Jun 27 19:38:32 Neko: The issue is the kernel refusing to load this particular initrd, full stop. Jun 27 19:38:52 Neko: Talking about how to build it differently doesn't in any way change that the kernel doesn't like this one. :P Jun 27 19:38:54 oh shit, we saw that a bunch of times on efika and 3.2/3.4/3.5 kernels.. Jun 27 19:39:02 at some point it just magically solved itself Jun 27 19:39:17 I think we bumped a kernel version and redid our config.. Jun 27 19:39:21 That's comforting. Jun 27 19:40:03 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. Jun 27 19:40:29 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. Jun 27 19:40:37 Creating unbootable systems on upgrades is, well, bad. Jun 27 19:40:53 the problem is it's most likely some u-boot weirdness. Jun 27 19:41:33 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? Jun 27 19:41:45 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 Jun 27 19:42:11 does u-boot invalidate the caches over the kernel and ramdisk area as it puts them there, or before boot? Jun 27 19:42:26 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. ;) Jun 27 19:42:43 for uimage it can know the sizes involved but for a zimage and raw initrd I wonder how it'd know what to invalidate Jun 27 19:43:18 Neko: Yeah, I'm not sure what crazy uBoot does here. Jun 27 19:44:07 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 Jun 27 19:44:23 did you enable all the arm errata in the kernel just in case? :) Jun 27 19:45:05 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... Jun 27 19:45:37 robher: Oh, we already have "real customers" installing precise on highbank despite the lack of installer? Jun 27 19:45:48 robher: Or bleeding edge folks using quantal? Jun 27 19:46:18 Neko: L2 and L1 data caches are off in u-boot. Jun 27 19:46:21 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 Jun 27 19:48:53 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. Jun 27 19:50:28 robher: We should make sure we get the installer bits in precise-proposed ASAP, then. Jun 27 19:50:31 robher: precise highbank is dep-wait a kernel SRU at the moment Jun 27 19:50:56 NCommander: One in the PPA, or one in proposed? Jun 27 19:51:20 infinity: in the PPA. The previous upload added highbank but forgot the udebs Jun 27 19:51:50 NCommander: Oh, whoops. Jun 27 19:51:53 so the fix for that had to wait for the next SRU cycle; can't upload d-i without it since it wants udebs Jun 27 19:52:27 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. Jun 27 19:52:36 NCommander: But are all the ducks in a row WRT flash-kernel and such? Jun 27 19:52:53 infinity: yeah, I'm sitting on it right now, though I haven't uploaded to proposed Jun 27 19:53:08 (guess it wouldn't actually interfere with anything so I could just "do it") Jun 27 19:53:28 NCommander: Please do, so we can review in small chunks instead of one massive vomit of SRU. Jun 27 19:53:47 infinity: will try to get everything uploaded by EOD then Jun 27 19:58:18 robher, turning them on might make it load faster :) Jun 27 20:04:13 infinity: this might be some brokenness in bootz cmd. Putting the initrd in an uInitrd works. Jun 27 20:05:18 robher: That's doubly disconcerting. Jun 27 20:05:39 robher: Also, I thought you said that feeding it raw to qemu also failed? Jun 27 20:05:46 robher: Which would rule out uboot/bootz. Jun 27 20:06:11 robher: Unless the highbank qemu actually starts by feeding the kernel/initrd arguments to uboot. :) Jun 27 20:06:15 (I haven't played with it) Jun 27 20:13:52 14:12 when i was doign highbank config fixes we had a thing where the initramfs would fail decompression Jun 27 20:13:56 14:12 but if you then hit ^d it was all in there Jun 27 20:13:58 14:12 and it was caused by the length of the initrd being somehow out of sync with what was loaded Jun 27 20:14:01 14:12 the conjecture was the loader was rounding down the size and not loading enough blocks Jun 27 20:14:42 there was something a Jun 27 20:14:56 about the boot loader needing to be told the exact size or something Jun 27 20:15:11 rbasak i think you were involved and may be able to use the right words Jun 27 20:16:35 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. Jun 27 20:16:40 rbasak: ^ Jun 27 20:16:57 right Jun 27 21:05:59 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 Jun 27 22:12:51 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. Jun 27 22:20:19 rbasak, infinity: Looks like u-boot is overlapping its initrd copying with its stack. Jun 27 22:27:41 rbasak: You mean increase the size that you tell u-boot, or pad the initrd.gz file with zeroes past an arbitrary boundary? Jun 27 22:27:57 rbasak: Cause we could certainly incorporate the latter as a hack in the d-i builds, if it works. Jun 27 22:28:55 robher: That sounds unpleasant. Jun 27 22:29:26 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. Jun 27 22:30:13 sp start = 0x1FF00F60 and ramdisk load end = 0x1ff006c3 Jun 27 22:31:58 That doesn't look overlapped to me, unless 6 suddenly became larger than F when I wasn't looking. Jun 27 22:32:10 evidently the CONFIG_STACKSIZE value is no longer used and setting it to 128K is pointless Jun 27 22:32:29 stacks grow down Jun 27 22:32:57 Ahh. And it's larger than f60-6c3, I take it? Jun 27 22:34:39 Anyhow. Back to work. Jun 27 22:35:24 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. Jun 27 22:36:54 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. Jun 27 22:39:18 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. Jun 27 22:48:52 infinity: this could affect any ARM board and may be same problem seen on efika boards Jun 27 22:50:55 I thought of that but I couldn't prove it at all Jun 27 22:51:23 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 Jun 27 22:52:23 so, sp start = top of stack, growing down into memory? Jun 27 22:52:52 yes Jun 27 22:53:06 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 Jun 27 22:53:33 are you saying on bootm or bootz it's copying the ramdisk out of the way of the kernel or some shit? Jun 27 22:54:09 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..... Jun 27 22:54:58 robher: Yeah, setenv obviously doesn't help for either PXE or people booting "raw" from the uboot CLI (unless they know the trick). Jun 27 22:55:01 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. Jun 27 22:55:15 robher: But if getting firmware updates out seems reasonable, I'll just happily forget we had this conversation. Jun 27 22:55:22 infinity, initrd_high seems like a stupid hack to me. we set it on our development u-boot in the environment. Jun 27 22:55:33 is this documented somewhere? Jun 27 22:55:35 what conversation... Jun 27 22:56:30 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 Jun 27 22:56:41 There is a CONFIG flag that does the same thing and I can set it in the default environment. Jun 27 22:56:45 wiki page at denx, or on an ubuntu bug properly investigated? Jun 27 22:58:54 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. Jun 27 23:00:03 Neko: can I borrow the hammer when you're done with it? ;) Jun 27 23:03:39 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 Jun 27 23:03:58 If it's stack memory overlap I'm not sure why that worked though Jun 27 23:04:28 Unless stack is being miscalculated and dependent on the initrd size? Jun 27 23:04:40 But if it grows down, that makes no sense Jun 27 23:04:42 (to me) Jun 27 23:04:53 Anyway, it sounds like robher has worked out the problem Jun 27 23:07:49 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. Jun 27 23:09:19 So how come the stack is placed right next to the initrd, anyway? :) Jun 27 23:10:10 because u-boot is stupid Jun 27 23:11:09 at least everything will be better with uefi. Jun 27 23:13:20 I found the docs, and the code itself is obtuse to say the least Jun 27 23:13:56 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"? Jun 27 23:15:20 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 Jun 27 23:15:34 the address you load the ramdisk to is basically irrelevant, I can't imagine why u-boot would copy it around at all Jun 27 23:18:26 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 Jun 27 23:18:26 high so you don't LOAD over your stack. Copying is redundant Jun 27 23:19:30 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? Jun 27 23:19:50 even a 4kb stack Jun 27 23:20:11 * Neko goes to buy some hammer polish Jun 27 23:20:17 lol Jun 27 23:21:10 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.. Jun 27 23:21:34 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. Jun 27 23:21:59 is this for situations where u-boot has no clue what the memory size is when it loads? Jun 27 23:22:44 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 :( Jun 27 23:23:07 hell on mx51 etc. why not keep running u-boot out of iram, and put the stack in iram? Jun 27 23:24:43 I think I might cry :( Jun 27 23:28:37 Neko: running the stack out of iram makes sense really Jun 27 23:29:34 depending how much there is of course Jun 27 23:32:29 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. Jun 27 23:32:43 but by the time u-boot loads due to the imx boot process, memory size is well known Jun 27 23:32:58 so it can go in ram. but still.. fucksake. Jun 27 23:33:42 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 Jun 27 23:34:05 * Neko is wondering why u-boot doesn't build if you turn off zlib and gzip support even though it never uses it **** ENDING LOGGING AT Thu Jun 28 02:59:58 2012