/srv/irclogs.ubuntu.com/2012/06/27/#ubuntu-arm.txt

eswensonis this the right place to discuss getting an ubuntu distro for the igepv2 board?03:41
eswensonI 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:44
infinityeswenson: 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
infinityeswenson: Have you tried a stock 12.04/omap image?03:47
eswensonI haven't yet.  If there is a prayer of a chance that it would work, I'll give it a whirl.03:48
infinityI 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
eswensonI 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
infinityThe 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:49
eswensonI'll check it out.  Thx.03:50
infinityIf 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
infinityBut if you're just looking for "a decent ARM device to play with", Pandas are great.03:51
eswensonYes, the Pandaboard ES looks really nice.  Appears to cost about $180.03:54
prp^2infinity: beagle community is far more active as there are more people actually designing products around AM3xxx series03:56
eswensonprp^2 are you saying that the beagle community is more active than the panda board community?04:02
prp^2eswenson: yea it is about a 4 to 1 ration on activity04:03
=== prp^2 is now known as prpplague
eswensonLast time i checked beagle board, the board seemed quite inferior to the igepv2 board.  But I'll look again.04:03
prpplagueeswenson: 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 marked04:04
prpplagueeswenson: igepv2 is basically a beagle, and many of the igepv2 folks share the beagle community areas04:04
prpplagueeswenson: there is only the panda , no clones such as the igepv2 for beagle04:05
eswensonI 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
eswensonBut I  have this board (igepv2) and was hoping to bring it to life with a more current kernel/distro.04:06
eswensonBut if it's really a waste of time, then I'd be up for getting another board....04:06
prpplagueeswenson: basically what works for beagle works for igepv204:06
eswensonSo 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
prpplagueeswenson: yea04:07
eswensonSame u-boot-arm and x-loader, or are these specific to the igepv2?04:07
prpplaguehttp://www.elinux.org/BeagleBoard#IGEPv204:08
eswensonSo I'd probably need additional drivers for the on-board ethernet, wifi, and bluetooth...04:09
prpplagueeswenson: probably not, most of the beagle builds have all the support for the clones as well04:09
prpplagueeswenson: igepv2 has been around for some time04:09
prpplagueiirc since aroun 200804:10
* prpplague checks04:10
eswensonyeah.  I bought mine in 2010.04:10
eswensonwill armhf images work on the igepv2?  I thought I needed armel?04:13
eswensonthe 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:21
prpplagueeswenson: thats probably long out of date04:38
prpplagueeswenson: when was the page last updated?"04:38
eswensonPage was last modified on 12 June 2012.  (http://elinux.org/BeagleBoardUbuntu)06:25
=== prpplague is now known as prp^
=== LetoTheII is now known as LetoThe2nd
twbtf101, running oneiric armel but with armhf and precise added in post-install.  apt.conf has APT::Default-Release "oneiric";09:03
twbWhen I pull in mplayer, I get: mplayer: Symbol `ff_codec_bmp_tags' has different size in shared object, consider re-linking09:03
twb...and mplayer: relocation error: mplayer: symbol __aeabi_f2ulz, version LIBAVCODEC_53 not defined in file libavcodec.so.53 with link time reference09:03
twbIs it obvious to anyone which package(s) should be up/downgraded to address that?09:04
twbPlan B is to just poke at the libavcodec packages and see what happens.09:04
twbAh, oops, I thought I was testing the mplayer from precise, but it was the oneiric mplayer, so no surprise it wasn't working.09:08
twbCool, works now (apt-get install mplayer/precise --no-install-recommends libavformat53/precise libavcodec53/precise libva1/precise).09:14
=== XorA|gone is now known as XorA
OrbHaving 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:44
OrbCan 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 idea09:47
ogra_you probably want to go to #debian-arm on oftc.net09:48
Orbthank you will do09:48
angsI 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:22
angsdo I do something wrong?13:23
angsor what do I need to do next?13:32
ogra_it should just work, do you have a proper power supply attached ?13:35
ogra_iirc the bone uses a lot less power than the XM, you will need some decent PSU for driving the USB hub on board13:36
angsI am supplying it by a 5V, 1A adapter13:36
ogra_not sure 1A is sufficient13:37
angsuser manual says 1A is minimum at some pages, on other pages 1.5A min13:37
ogra_i know  th epandaboard wont work with less then 2A13:37
ogra_minimum, yeah13:38
angsI saw youtube videos that they just supply with usb to mini usb13:38
ogra_that means with nothing attached at all13: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 USB13:38
angsso when I have a proper power supply, it should work fine, right?13:38
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, yeah13:39
angsso I need to wait one more day to try it :(13:39
angsthank you for your help13: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 issue13:40
angsI just wonder if there is any additional step that I need to do after booting it13:40
ogra_in any case you should see bootloader messages on the serial port13:40
angsI will have the serial cable tomorrow13:40
ogra_great13:41
angsI can not access it through the ethernet connection, right?13:41
ogra_??13:41
ogra_nope13:41
ogra_you have to pulg it into the serial port of the beagle13:41
ogra_*plug13:41
angsgot it. is there any video instruction for it?13:42
ogra_i dont think so ... and i would be surprised if you need it13:43
ogra_the cable usually only has a serial plug on one side and an USB plug on the other13:43
ogra_serial goes into the serial socket on the board, usb into your PC13:44
angsI wanted to mean the ubuntu installation to a beagleboard13:44
ogra_nope, no video of that either13:44
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 is13:45
angsthat 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 default13:47
angsah ok13:48
angsso I will wait for tomorrow to proceed. thanks a lot again13:48
angsdo you know the reason why beagleboard links to elinux for ubuntu? http://beagleboard.org/project/ubuntu/13:50
angswhy not https://wiki.ubuntu.com/ARM/13:50
angsI mean as a homepage13:50
ogra_nope, no idea13:51
ogra_ask in #beagle :)13:51
angsright:) thank you13:51
ogra_someone there likely maintains these links13:51
janimomarvin24, 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:02
janimomarvin24, 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 which14:03
marvin24janimo: drm is only a prove of concept and not planed to upstream in the current form14:04
marvin24on the tegra list there is a discussion on how to setup the device tree info currently14:04
marvin24and code comes after that ...14:04
marvin24also there is almost no power management support on mainline14:05
janimomarvin24, is that because overall PM framework has changes so much that the pm code in 3.1 is of no use?14:05
janimo3.1 and 2.6.x which works on ac10014:05
marvin24janimo: I surely can't14:08
marvin24if you like to care for forward porting 6000 patches, you can try14:08
janimomarvin24, I mean the reason for PM framework changes between 3.1 and 3.6 is why it needs a complete rewrite?14:09
marvin24janimo: honestly, I don't know14:09
marvin24I guess it is more lag of developers14:10
janimomarvin24, 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 is14:10
janimoso it makes planning for packaging a bit harder :)14:10
marvin24yes, nvidia never was very "communicative"14:10
marvin24janimo: did you saw the post of Stephen Warren on the xorg list?14:11
janimomarvin24, I am not following that list, so no14:11
janimolink?14:11
marvin24sorry, it was kernel summit: http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-June/000304.html14:12
marvin24I think he is open for more responses14:12
=== zyga is now known as zyga-food
janimomarvin24, thanks, reading now15:03
=== zyga-food is now known as zyga
robherNCommander: 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:31
robhermd5 sum is okay though...16:35
infinityrobher: The initrd from the archive, or some homebrew thing from NCommander?16:41
robherinfinity: from the archive. uploaded today.16:43
infinityrobher: zcat initrd.gz | cpio -t looked fine to me.16:43
infinityAs did actually extracting it.16:43
infinity(base)adconrad@cthulhu:~/hb$ zcat initrd.gz | cpio -i16:43
infinitycpio: dev/console: Cannot mknod: Operation not permitted16:43
infinitycpio: dev/null: Cannot mknod: Operation not permitted16:43
infinity24314 blocks16:43
infinity^-- Looks fine.16:44
infinityrobher: 20101020ubuntu150?16:45
robherinfinity: Those commands work for me too. Strange...16:48
robherinfinity: yes, 20101020ubuntu15016:48
robherinfinity: seems --to-stdout doesn't work. Other initrds that work have the same message. Back to u-boot debug...16:50
RoyKhm... is -d implicit with cpio these days?16:52
janimomarvin24, do you know ny tegra specific fbcon issues with 2.6.39?17:06
gildeannexus 7 live: https://developers.google.com/events/io/17:19
robherinfinity: 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:29
infinityrobher: Seriously?  That's disconcerting.  And a much deeper bug, then.18:30
infinityrobher: And I'm trying to decide if I blame it on gzip or the kernel.18:30
infinityrobher: 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
scienteswow18:32
scientescould be the convervativeness of the offset on decompression18:32
scientesb/c its a one-shot decompressor and it decompresses in place in ram18:32
infinitySure.  Could be a lot of things.18:33
infinityBut 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
robherinfinity: perhaps the kernel's gunzip doesn't like something in newer gzip? I'm on precise.18:33
scientesoh wait, robher are you using 3.5?18:34
infinityMaybe I should just switch debian-installer to producing lzma initrds by default and scream "LA LA LA".18:34
infinityscientes: No, he's using 3.218:34
scientesok, cause there is a bug that was created in merging otherwise good code in 3.5, for arm compressoin18:34
infinityOr, wait.  This was highbank?18:34
infinityI've lost track.18:34
robherThe kernel log has "rootfs image is not initramfs (no cpio magic); looks like an initrd" then later...18:35
infinityhighbank is 3.5 in quantal, yes.18:35
scienteswell that that is probably it18:35
scientesthe problem is that the decompression stuff declres STRING_H18:35
infinityBut he claimed he tried the initrd with older kernels.18:35
scientesand prevents the real string.h loading18:35
infinityrobher: You tried the quantal initrd with a precise kernel and got the same error?18:35
scientesand linking with early boot/decompression stuff18:35
scientesnow that was already there, but some new code now actually wants to use string.h18:36
scientesi did some messaging on the mailinglist of the person's code that was affected, but nothing came of it18:36
robherI've tried mainline 3.2 + highbank patches and see the problem.18:38
infinityCould the highbank patches be backporting this problematic bit that scientes speaks of?18:39
scientes> the recently added to arm, CONFIG_KERNEL_XZ is broken because18:40
scientes> arch/arm/boot/compressed/decompress.c defines _LINUX_STRING_H18:40
scientes> overriding <linux/string.h> used in include/linux/dynamic_debug.h:11118:40
=== zyga is now known as zyga-afk
scientesi didn't really research the scope, it could go beyond xz, a kernel i compiled with gzip didn't boot for me18:41
infinityscientes: And, despite that being an XZ patch, that breaks all compression methods?18:41
infinityFun.18:41
scientesinfinity, it was actually the debug patch that was broken18:41
scientesboth were merged inthe same window18:41
scientesso both are to blame18:41
scientesit was a conflict that wasn't seen18:41
infinityCheck.18:41
infinityWell, if this is the bug, we should report it, track it, and fix it.18:42
infinityrobher: Is your "mainline+highbank" kernel a homebrew, or our 3.2.0 from precise-updates?18:42
scientesi 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 problem18:42
scientesi can only think that it was put there to try to make stuff leaner18:43
scientesanywas, may not be the problem, but its definitely a bug18:44
robherinfinity: it is not an ubuntu kernel. It's roughly what I've published on our git tree.18:45
robherI did find this: I'm seeing where I have to remove CONFIG_BLK_DEV_RAM from the kernel18:45
robherto get it to boot with an external initramfs image. It says the image18:45
robheris not good (junk in it), but it boots.  The same image boots fine18:45
robherwhen built into the kernel using INITRAMFS_SOURCE, even with18:45
robherBLK_DEV_RAM in the kernel.18:45
robherfrom the lakml18:46
infinityrobher: Can you check if it works with the precise 3.2.0 kernel?18:48
infinityrobher: Just as a datapoint.18:49
infinityIf the initramfs really doesn't load with ANY kernel, I'd be looking to blame gzip.18:49
devikerhello, what toolchain are you using for allwinnerA10 (it's an armv7 but the images people have built are for armv5)18:49
scientesdeviker, all ubuntu is armv7, even the soft float armel18:50
infinityscientes: (sort of)18:50
infinityI guess I shouldn't confuse people, though.18:50
scientesinfinity, are you referencing assembly that isn't ported?18:51
scientesor is certainly C compiled with differn't settings18:51
infinitydeviker: 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
infinityscientes: No, I'm refering to the fact that quantal's armel toolchain is armv5t.18:51
infinityscientes: Shh, don't tell anyone.18:51
scientesoh wow18:51
scientesjust the toolchain, or its settings?18:52
devikerthanks, I've to go I'll be back in a hour18:52
scientescause you keep telling everyone they cant run ubuntu on their sheevaplugs or rasperri pis18:53
infinityscientes: 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
infinityscientes: And yeah, booting quantal/armel on a Pi would fail miserably right now, cause half the archive is still v7. ;)18:53
infinityscientes: Lazy organic zero-effort rebuild, for the win.18:54
infinityscientes: 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
infinityscientes: universe won't be so lucky.18:54
scienteswell im liking my systemd setup on my sheevaplug ;)18:54
scientes(with debian)18:55
infinityI assumed, yes. ;)18:55
robherinfinity: same problem with precise 3.2.0-26.4118:58
* infinity grumps.18:59
infinityOf course, that still doesn't rule out the highbank sauce.18:59
infinitySomeone should try it with an i386 kernel. :P18:59
robherinfinity: the first version of the highbank installer posted worked fine. That was on 3.4, but the highbank parts haven't really changed.19:05
infinityrobher: So, there is a kernel that will load that initrd?19:08
robherinfinity: no, no. A previous quantal initrd for highbank worked.19:12
infinityrobher: Oh, yeah, that's probably a less interesting datapoint.19:12
infinityrobher: If I can find a round tuit, I'd like to know if *any* kernel can decompress the new initrd.19:13
infinityomap4, something not ARM at all, whatever.19:13
infinityIf it universally explodes on everything, then it's obviously(ish) something wrong with how it's being generated.19:13
infinityIf only highbank kernels complain about it, then there's something wonky in that patchset tickling a misbehaviour.19:14
infinityBut, 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:14
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:15
robherinfinity: 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 installer19:19
infinitygzip -v9f ./tmp/highbank_netboot/initrd19:23
infinity^-- From the log.19:23
infinityNothing special.19:23
infinityThough the -9 may be why your size differed.19:23
robherinfinity: with -9 the size is the same before and after and it doesn't work.19:25
infinityCurious indeed.19:26
infinityCause we build all our initrds with -919:26
infinityAnd always have.19:26
infinitySo...19:26
Nekoyerg, 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:30
Nekogiven 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:31
infinityNeko: It matters because uBoot sucks.19:33
Nekoin what way?19:34
Nekou-boot doesn't decompress initrds19:34
infinityNeko: Smaller is much better, and I've never seen the decompression take anywhere near as long as the load.19:34
Nekoor.. let me put that a better way. it damn well shouldn't.19:34
infinityNeko: No, uBoot does the load, and it's awful at it.19:34
infinityNeko: Hence, smaller better.19:34
Nekookay so you're generating uncompressed cpio initrds and then letting mkimage compress them?19:34
infinityNeko: No.  These ones aren't mkimaged.  highbank is a unique snowflake.19:35
Nekobootz? :)19:35
infinityNeko: Yeahp.  Though, feeding them raw to qemu appears to exibit the same issues, to it's not the bootloade doing bad things.19:35
Nekothat'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
robherinfinity: u-boot is the snowflake. :)19:36
Nekokernel supports xz and xz initrds actually decompress faster than gzip ones somehow :)19:36
infinityNeko: Yeah, yeah.  None of this is news.19:37
Nekoeven 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
Nekoso xz initrd doesn't work either, or?19:37
infinityNeko: 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
Nekowhat is the issue, just a random borkage?19:38
infinityNeko: The issue is the kernel refusing to load this particular initrd, full stop.19:38
infinityNeko: Talking about how to build it differently doesn't in any way change that the kernel doesn't like this one. :P19:38
Nekooh shit, we saw that a bunch of times on efika and 3.2/3.4/3.5 kernels..19:38
Nekoat some point it just magically solved itself19:39
NekoI think we bumped a kernel version and redid our config..19:39
infinityThat's comforting.19:39
Nekowell, 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
infinityGiven 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
infinityCreating unbootable systems on upgrades is, well, bad.19:40
Nekothe problem is it's most likely some u-boot weirdness.19:40
infinityrobher: 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
Nekothe 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 checked19:41
Nekodoes u-boot invalidate the caches over the kernel and ramdisk area as it puts them there, or before boot?19:42
infinityrobher: 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
Nekofor uimage it can know the sizes involved but for a zimage and raw initrd I wonder how it'd know what to invalidate19:42
infinityNeko: Yeah, I'm not sure what crazy uBoot does here.19:43
Nekosometimes 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 days19:44
Nekodid you enable all the arm errata in the kernel just in case? :)19:44
robherinfinity: 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
infinityrobher: Oh, we already have "real customers" installing precise on highbank despite the lack of installer?19:45
infinityrobher: Or bleeding edge folks using quantal?19:45
robherNeko: L2 and L1 data caches are off in u-boot.19:46
infinityrobher: 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.119:46
robherinfinity: 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:48
infinityrobher: We should make sure we get the installer bits in precise-proposed ASAP, then.19:50
NCommanderrobher: precise highbank is dep-wait a kernel SRU at the moment19:50
infinityNCommander: One in the PPA, or one in proposed?19:50
NCommanderinfinity: in the PPA. The previous upload added highbank but forgot the udebs19:51
infinityNCommander: Oh, whoops.19:51
NCommanderso the fix for that had to wait for the next SRU cycle; can't upload d-i without it since it wants udebs19:51
infinityNCommander: 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
infinityNCommander: But are all the ducks in a row WRT flash-kernel and such?19:52
NCommanderinfinity: yeah, I'm sitting on it right now, though I haven't uploaded to proposed19:52
NCommander(guess it wouldn't actually interfere with anything so I could just "do it")19:53
infinityNCommander: Please do, so we can review in small chunks instead of one massive vomit of SRU.19:53
NCommanderinfinity: will try to get everything uploaded by EOD then19:53
Nekorobher, turning them on might make it load faster :)19:58
robherinfinity: this might be some brokenness in bootz cmd. Putting the initrd in an uInitrd works.20:04
infinityrobher: That's doubly disconcerting.20:05
infinityrobher: Also, I thought you said that feeding it raw to qemu also failed?20:05
infinityrobher: Which would rule out uboot/bootz.20:05
infinityrobher: Unless the highbank qemu actually starts by feeding the kernel/initrd arguments to uboot. :)20:06
infinity(I haven't played with it)20:06
infinity14:12 <apw> when i was doign highbank config fixes we had a thing where the initramfs would fail decompression20:13
infinity14:12 <apw> but if you then hit ^d it was all in there20:13
infinity14:12 <apw> and it was caused by the length of the initrd being somehow out of sync with what was loaded20:13
infinity14:12 <apw> the conjecture was the loader was rounding down the size and not loading enough blocks20:14
apwthere was something a20:14
apwabout the boot loader needing to be told the exact size or something20:14
apwrbasak i think you were involved and may be able to use the right words20:15
infinityapw: 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
infinityrbasak: ^20:16
apwright20:16
robherinfinity: 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 back21:05
rbasakrobher, 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:12
robherrbasak, infinity: Looks like u-boot is overlapping its initrd copying with its stack.22:20
infinityrbasak: You mean increase the size that you tell u-boot, or pad the initrd.gz file with zeroes past an arbitrary boundary?22:27
infinityrbasak: Cause we could certainly incorporate the latter as a hack in the d-i builds, if it works.22:27
infinityrobher: That sounds unpleasant.22:28
infinityrobher: 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:29
robhersp start    = 0x1FF00F60  and  ramdisk load end = 0x1ff006c322:30
infinityThat doesn't look overlapped to me, unless 6 suddenly became larger than F when I wasn't looking.22:31
robherevidently the CONFIG_STACKSIZE value is no longer used and setting it to 128K is pointless22:32
robherstacks grow down22:32
infinityAhh.  And it's larger than f60-6c3, I take it?22:32
infinityAnyhow.  Back to work.22:34
infinityrobher: 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:35
robherI'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:36
robhersetenv 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:39
robherinfinity: this could affect any ARM board and may be same problem seen on efika boards22:48
NekoI thought of that but I couldn't prove it at all22:50
Nekothe 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 stack22:51
Nekoso, sp start = top of stack, growing down into memory?22:52
robheryes22:52
Nekoif 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 to22:53
Nekoare you saying on bootm or bootz it's copying the ramdisk out of the way of the kernel or some shit?22:53
NekoI 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
infinityrobher: Yeah, setenv obviously doesn't help for either PXE or people booting "raw" from the uboot CLI (unless they know the trick).22:54
Nekojust 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
infinityrobher: But if getting firmware updates out seems reasonable, I'll just happily forget we had this conversation.22:55
Nekoinfinity, initrd_high seems like a stupid hack to me. we set it on our development u-boot in the environment.22:55
Nekois this documented somewhere?22:55
robherwhat conversation...22:55
Nekowe'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 releases22:56
robherThere is a CONFIG flag that does the same thing and I can set it in the default environment.22:56
Nekowiki page at denx, or on an ubuntu bug properly investigated?22:56
robherNeko, 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.22:58
robherNeko: can I borrow the hammer when you're done with it? ;)23:00
rbasakinfinity: 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 problem23:03
rbasakIf it's stack memory overlap I'm not sure why that worked though23:03
rbasakUnless stack is being miscalculated and dependent on the initrd size?23:04
rbasakBut if it grows down, that makes no sense23:04
rbasak(to me)23:04
rbasakAnyway, it sounds like robher has worked out the problem23:04
robherrbasak: 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:07
rbasakSo how come the stack is placed right next to the initrd, anyway? :)23:09
robherbecause u-boot is stupid23:10
robherat least everything will be better with uefi.23:11
NekoI found the docs, and the code itself is obtuse to say the least23:13
Nekothey'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:13
Nekokernel 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 is23:15
Nekothe address you load the ramdisk to is basically irrelevant, I can't imagine why u-boot would copy it around at all23:15
Nekothe 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 stack23:18
Neko high so you don't LOAD over your stack. Copying is redundant23:18
Nekoalso 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
Nekoeven a 4kb stack23:19
* Neko goes to buy some hammer polish23:20
lilstevielol23:20
NekoI 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
Nekobut 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
Nekois this for situations where u-boot has no clue what the memory size is when it loads?23:21
Nekobecause 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:22
Nekohell on mx51 etc. why not keep running u-boot out of iram, and put the stack in iram?23:23
NekoI think I might cry :(23:24
lilstevieNeko: running the stack out of iram makes sense really23:28
lilsteviedepending how much there is of course23:29
Neko128k 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
Nekobut by the time u-boot loads due to the imx boot process, memory size is well known23:32
Nekoso it can go in ram. but still.. fucksake.23:32
NekoI 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 again23:33
* Neko is wondering why u-boot doesn't build if you turn off zlib and gzip support even though it never uses it23:34

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!