[09:53] <ogra> asac, i milestoned bug #457878 (since it still exists with the recent BSP drop)
[09:53] <ubot4> Launchpad bug 457878 in linux-fsl-imx51 "imx51 on board ethernet plug/unplug events not detected" [Medium,Confirmed] https://launchpad.net/bugs/457878
[09:53] <ogra> cooloney, ^^^
[09:56] <cooloney> ogra: cool, will take a look when I am back to Shanghai, heh
[10:43] <asac> ogra: you are sure your modules are loaded?
[10:44] <asac> aka are you sure your kernel/initramfs you used for your uboot is identical with the one you have no your filesystem
[10:44] <asac> i had the same behaviour yesterday, but it was all a version mismatch
[10:44] <cooloney> dmart: thx for the email, could you please file a NEON bug in launchpad and assign it to me?
[10:44] <cooloney> dmart: then we can tracker the discussion
[10:45] <asac> ogra: asked for dmesg/syslog in bug
[10:50] <ogra> asac, ??
[10:51] <asac>  ogra in your ethernet bug
[10:51] <ogra> are you referring to the bug above ?
[10:51] <asac> or rather the bug you hi jacked
[10:51] <asac> yes
[10:51] <ogra> sure the modules are loaded
[10:51] <ogra> its not related to uboot
[10:51] <asac> yesterday you said there is no interface
[10:51] <asac> now its just LOWER_UP?
[10:51] <ogra> thats on a redboot booted system and is a long standing missing feature in the FEC driver
[10:52] <asac> yeah
[10:52] <asac> ok
[10:52] <ogra> it was missing in all kernel versions we ever had
[10:52] <asac> so that "no net at all" feature is fixed for you?
[10:52] <ogra> no
[10:52] <asac> where is that bug?
[10:52] <ogra> thats what i'm looking at atm, i just wanted to make sure the above bug isnt forgotten
[10:52] <asac> heh ok.
[10:53] <ogra> i havent filed it yet, just looking at uboot code to make sure we build the right driver
[10:53] <asac> do you see your interface at all?
[10:53] <asac> i saw it
[10:53] <asac> though i only have a read-only fs
[10:53] <ogra> yes, you can see it, but you cant bring it up
[10:54] <ogra> usually you see the kernel setting the MAC in demsg, that part is missing, i see it initializing the driver but the line with MAC is missing
[10:54] <asac> wireless is working flawlessly here :)
[10:54] <ogra> and ifconfig says it cant assign an address
[10:54] <asac> so i think its not a blocker to stop the uboot move in debian-cd
[10:55] <ogra> (where it refers to the MAC)
[10:55] <asac> yeah
[10:55] <ogra> the only interface the bnoard has doesnt work ..
[10:55] <ogra> i would consider that as a blocker :)
[10:55] <asac> a release blocker yes,
[10:55] <asac> but not a roll out blocker
[10:55] <ogra> well, at least highest prio
[10:56] <asac> sure, but we should do the uboot move before that
[10:56] <ogra> well, uboot needs an upload anyway
[10:56] <ogra> for the changed defaults
[10:56] <ogra> we also need to consider that an installed system might not have /boot on the second partition
[10:57] <ogra> i'm not sure how to solve that yet but have some ideas (if uboot doesnt stop script execution we can just try to load from part1 and then from part2, but i'm not sure that works, needs testing)
[10:57] <asac> ogra: atm we have a boot floppy and an install floppy. we can assume that its always on partition 2 for the boot floppy thing
[10:57] <asac> its not a real solution
[10:58] <asac> but we need to work on scripts to work on that
[10:58] <asac> how are you doing that on redboot?
[10:58] <ogra> we cant assume that once we install uboot to mtd flash
[10:58] <ogra> redboot never goes into flash
[10:58] <asac> once we install it there
[10:58] <ogra> as soon as you boot from flash the first partition will be gone
[10:58] <asac> at that point we must be able to interate
[10:58] <ogra> thats what davidm wants as final install setup
[10:59] <asac> sure
[10:59] <asac> but we are not there yet ;)
[10:59] <ogra> so users just flip a DIP switch in the end
[10:59] <ogra> no, but i'd like to know in advance if it works :)
[10:59] <asac> right. thats understood. just doesnt need to happen on the first iteration
[10:59] <asac> it has to be made working.
[11:00] <ogra> it works already :)
[11:00] <asac> so you have an iterating boot.scr?
[11:00] <ogra> but i dont feel good with all the hardcoding
[11:00] <ogra> no
[11:00] <ogra> it works as is
[11:00] <asac> right. so dont bother about that
[11:00] <ogra> with the hardcoded part2 loading
[11:00] <asac> what i meant with has to be made working is that we can do that
[11:00] <asac> yes.
[11:00] <asac> 11:59 < asac> right. thats understood. just doesnt need to happen on the first iteration
[11:01] <asac> 11:59 < asac> it has to be made working.
[11:01] <asac> -> thats iterating boot.scr
[11:01] <asac> ok
[11:01] <asac> i am getting cigarettes and coffee
[11:01] <asac> and then will stop bothering you ;
[11:01] <asac> )
[11:01] <ogra> if i can put a bootscript into the defaults that tries part1 and moves on to part2 (without .scr since we need to load that as well) i prefer to do that directly
[11:02] <ogra> currently the only thing i want the scr for is the kernel cmdline
[11:02] <asac> only boot.scr can test for something afaik
[11:02] <asac> so you cannot test if something succeeded
[11:02] <ogra> boot.scr just replaces the bootcmd in the uboot defaults afaik
[11:02] <asac> it gets compiled afaik
[11:02] <asac> the whole for and if stuff is not available at command prompt
[11:02] <ogra> it just gets turned into a file uboot can load
[11:03] <ogra> but the content is what you see in printenv at the uboot prompt
[11:03] <ogra> so everything we do in .scr files should be possible directly too
[11:04] <ogra> afaik you can do "if ... then ... etc" in the hardcoded bootcmd
[11:05] <asac> i dont see any docs about that
[11:05] <asac> if you find that let me know
[11:05] <asac> uboot has really sucky documentation
[11:06] <asac> http://www.denx.de/wiki/view/DULG/CommandLineParsing
[11:07] <asac> bootm $addr1 || bootm $addr2 || tftpboot $loadaddr $loadfile && bootm
[11:07] <asac> ogra: ^
[11:07] <asac> so you can test that etc.
[11:08] <ogra> well, thats already what i look for
[11:08] <ogra> so we need hush shell support builtin
[11:10] <ogra> aha, needs the SHELL_HUSH option set at build time
[11:10]  * ogra looks in the code
[11:13] <ogra> CONFIG_SYS_HUSH_PARSER :) there it is
[11:16] <asac> yes
[11:18] <ogra> http://paste.ubuntu.com/356511/ has the full config in case someone wants to look :)
[11:18]  * ogra wonders if #define CONFIG_FEC0_PHY_ADDR	0x1F is our prob with the NIC
[11:35]  * ogra builds
[11:35] <ogra> asac, how about ext2 support while i'm at it, do you want that ?
[11:38] <ogra> make[2]: Entering directory `/uboot-imx-2009.08/fs/fdos'
[11:38] <ogra> ar crv /uboot-imx-2009.08/build/build-imx51/fs/fdos/libfdos.a
[11:38] <ogra> make[2]: Leaving directory `/uboot-imx-2009.08/fs/fdos'
[11:38] <ogra> hmm
[11:39] <ogra> i wonder if fdos is actually the better fat filesystem :)
[11:40] <ogra> mxc_fec.c: In function 'mxc_fec_initialize':
[11:40] <ogra> mxc_fec.c:781: warning: passing argument 1 of 'mxc_fec_set_mac' from incompatible pointer type
[11:40] <ogra> mxc_fec.c:725: note: expected 'struct fec_info_s *' but argument is of type 'struct fec_info_s (*)[1]'
[11:40] <ogra> AHA !
[11:40] <ogra> i guess thats the NIC issue
[11:54] <asac> ogra: you can just include that i guess
[11:54] <ogra> i think we should
[11:54] <asac> do it
[11:54] <ogra> having /boot ext2 formatted will gain us a lot more flexibility
[11:54] <ogra> i.e. symlinks
[11:55] <ogra> so we can have uimage being linked to uimage-$version
[11:55] <asac> yes, go for it
[11:55] <ogra> yup, will do
[11:55] <ogra> testing hush support first
[11:55] <asac> its just a config flag after all
[11:55] <asac> right
[11:55] <asac> hush + ext2 + fix fec
[11:55] <asac> if you want me to lok at that code i can check
[11:56] <asac> plars: so when did dove regress exactly? do we know that?
[11:57] <ogra> asac, fec ? yeah, that would help, so i can concentrate on the script
[11:57] <asac> ok ... let me use jocote ;)
[11:57] <asac> ogra: that happens on current archive uboot too, right?
[11:58] <ogra> gah, i hate that sshd doesnt log me out if i shut down the babbage
[11:58] <ogra> asac, yea, thats what i'm building
[12:08] <ogra> BBG U-Boot > setenv myload 'if mmcinfo; then echo MMC found;else echo MMC not found;fi'
[12:08] <ogra> BBG U-Boot > print myload
[12:08] <ogra> myload=if mmcinfo; then echo MMC found;else echo MMC not found;fi
[12:08] <ogra> BBG U-Boot > run myload
[12:08] <ogra> Device: FSL_ESDHC
[12:08] <ogra> Manufacturer ID: 1
[12:08] <ogra> OEM: 5041
[12:08] <ogra> Name: SM06G
[12:08] <ogra> Tran Speed: 25000000
[12:08] <ogra> Rd Block Len: 512
[12:08] <ogra> SD version 2.0
[12:08] <ogra> High Capacity: Yes
[12:08] <ogra> Capacity: 1945882623
[12:08] <ogra> Bus Width: 4-bit
[12:08] <ogra> MMC found
[12:08] <ogra> BBG U-Boot >
[12:08] <ogra> SWEET !
[12:08] <asac> ogra: can you say something like:
[12:08] <ogra> so now we can iterate over partitions, look for /casper etc
[12:08] <asac> if fatinfo mmc 0:2; then
[12:09] <ogra> sure
[12:09] <asac> if fatload mmc 0:2 /boot/...; then
[12:09] <ogra> well, fatls rather
[12:09] <asac> ogra: where is that documented
[12:09] <ogra> yeah, exactly
[12:09] <asac> i didnt see that on that patge
[12:09] <ogra> 14.2.16.3. Hush shell scripts
[12:10] <ogra> it supports similar syntax to shell
[12:10] <asac> ok
[12:10] <asac> still thats not a reference
[12:10] <asac> its just examples
[12:10] <asac> bad doc
[12:10] <ogra> well, as long as it works i dont care :)
[12:10] <asac> is hushshell some wider standard
[12:10]  * asac checks google
[12:10] <ogra> no, its uboot specific
[12:11] <asac> seems not
[12:11] <asac> yeah
[12:11] <asac> so ok. as long as it just works ;)
[12:11] <ogra> i'm happy with if, for, while and until :)
[12:12] <ogra> we can write a clever load script now that loads the .scr from predefined locations ... in the scr we can then put all the load commands
[12:12] <ogra> that gives us most flexibility
[12:13] <ogra> it expecially solves the prob that we have to set the UUID on cmdline after install
[12:14] <ogra> BBG U-Boot > if fatinfo mmc 0:0; then echo fat found on partition0; else echo no fat on partition0;fi
[12:14] <ogra> ** Partition 0 not valid on device 0 **
[12:14] <ogra> ** Unable to use mmc 0:0 for fatinfo **
[12:14] <ogra> no fat on partition0
[12:14] <ogra> heh
[12:15] <ogra> BBG U-Boot > if fatinfo mmc 0:2; then echo fat found on partition2; else echo no fat on partition2;fi
[12:15] <ogra> Interface:  MMC
[12:15] <ogra>   Device 0: Vendor: Man 015041 Snr 41a4343b Rev: 9.4 Prod: SM06G
[12:15] <ogra>             Type: Removable Hard Disk
[12:15] <ogra>             Capacity: 5743.0 MB = 5.6 GB (11761664 x 512)
[12:15] <ogra> Partition 2: Filesystem: FAT16 "           "
[12:15] <ogra> fat found on partition2
[12:15] <ogra> cute
[12:16]  * ogra goes to make some coffee and will then work out a little script :)
[12:29] <ogra> hmm first i should enable ext2 i guess
[12:30]  * asac grabs more coffee while ogra makes good progress
[12:30]  * asac takes the cheerleader role for now
[12:30] <ogra> heh
[12:39] <ogra> ok, uploaded
[12:46] <asac> ogra: wait ;)
[12:46] <ogra> to late :)
[12:47] <asac> ogra: jocote:~asac/fix_fec_warnings.patch
[12:47] <asac> try that
[12:47] <asac> let me know if that works, there is a bunch of odd code surrouding that
[12:47] <ogra> will do
[12:47] <asac> so it could well be that it doesnt and i have to fix a lot of code
[12:47] <asac> but the warning is gone that way
[12:47] <asac> but fec_initialize is a mystery code wise ;)
[12:47] <asac> int mxc_fec_initialize(bd_t *bis)
[12:47] <asac> {
[12:48] <asac>         for (i = 0; i < sizeof(fec_info) / sizeof(fec_info[0]); i++) {
[12:48] <asac> feels they are on crack ;)
[12:48] <ogra> heh
[12:48] <asac> i is used like fec_info[i]
[12:48] <asac> but lets see ... if it just starts working let me know ... i can do the upload
[12:50] <ogra> i'm doing a testbuild anyway so i can quickly shove that in
[12:50] <asac> you were too eager ;)
[12:50] <asac> but well, you probably need some uploads just to excersize
[12:50] <ogra> nah, i just didnt want the changes to get lost :)
[12:51] <ogra> we have anout free version numbers :)
[12:51] <ogra> *enough
[12:51] <asac> yeah. but if you upload quickly, it will end up with a upload failure
[12:51] <asac> and the ftbfs will be stuck forever on ubuntuwire
[12:51] <asac> e.g. .deb doesnt get accepted because newer source is avail
[12:52] <ogra> nah, ubuntuwire is clever enough
[12:53]  * ogra fires off dpkg-buildpackage ... 
[12:53] <ogra> 20min or so
[12:59] <ogra> i wonder if we should have other filesystems too
[12:59] <ogra> ubifs, cramfs and jffs2 might be some that developers might use
[13:00] <ogra> (ext2 passes btw)
[13:01] <ogra> asac, mxc_fec.c passes the build with no errors now
[13:01] <persia> I'd like ubifs support.
[13:01] <persia> But I'm not sure I'd want a ubifs /boot, just because it'd be a pain to set up initially.
[13:01] <ogra> right
[13:02] <ogra> its only about /boot atm
[13:02] <ogra> i wonder what would happen if i just enabled USB support :)
[13:02] <ogra> something to play with on a weekend though
[13:03] <persia> For /boot, don't bother about ubifs or jffs2.
[13:03] <ogra> yeah
[13:03] <persia> I'm less familiar with cramfs: dunno if that'd be useful.
[13:03] <ogra> ext3 or 4 would be nice, but i doubt anyone ever implemented that
[13:03] <persia> I *do* want to be able to put / on ubifs, but that's just a kernel thing.
[13:03] <ogra> yeah
[13:03] <asac> ogra: let me know if it *works*
[13:03] <asac> i know that the warning is gone ;)
[13:03] <ogra> heh
[13:04] <persia> I'm not a fan of journaled boot.  I use ext2 even on my amd64 systems.
[13:04] <ogra> will do, still building
[13:04] <asac> just not sure if it works at all because there is strange code
[13:04] <ogra> persia, to avoid fsck
[13:04] <persia> s$boot$/boot$
[13:04] <persia> fsck of 50MB is fast :p
[13:04] <ogra> still slows down the boot
[13:04] <ogra> especially on SD
[13:05] <persia> I guess.  I can't remember the last time I needed to fsck my /boot
[13:05] <asac> ogra: enable all fs that are available
[13:05] <asac> unless size explodes of course
[13:05] <ogra> asac, thats overkill
[13:05] <persia> (but I tend to reboot only for kernel updates)
[13:05] <asac> not sure how big uboot can be for flash usually
[13:05] <asac> ogra: its not overkill if size is ok
[13:05] <asac> otherwise stick with what we have now
[13:05] <ogra> as persia said, its unlikely that anyone puts /boot on ubifs ot jffs2
[13:06] <persia> asac: The rationale to *not* enable ubifs or jffs2 for /boot is that these filesystems need separate preparation and writing to flash, which gets ugly and complicated.
[13:06] <ogra> if we enable stuff it should add useful features
[13:06] <ogra> USB would rock
[13:06] <persia>  /boot on jffs2 basically means no kernel updates (in any sane way)
[13:06] <persia>  /boot on ubifs could be made to work, but it'd be a very ugly hack.
[13:06] <ogra> iots like squashfs, isnt it ?
[13:07] <ogra> you would have to recompress it each time
[13:07] <persia> jffs2 is like squashfs
[13:07] <persia> ubifs is just different.
[13:07] <ogra> (for a user perspective i mean)
[13:07] <asac> dont care. if we have reasons against those - and uboot bin gets bigger it can be ignored
[13:07] <persia> There's a procedure to create an initial filesystem, but writes thereafter are persistent.
[13:07] <asac> i want usb-storage ;)
[13:07] <asac> thats more important
[13:07] <ogra> uboot.bin gets surely bigger with each option i enable
[13:07] <persia> Yes.
[13:07] <ogra> and musb :)
[13:08] <persia> usb-storage is essential
[13:08] <ogra> but according to FSL it doesnt work
[13:08] <persia> Depends on who you ask.
[13:08] <ogra> i'll tinker with it in a spare minute some day
[13:08] <asac> they dont have the code for uboot there yet
[13:08] <asac> only thing i found was support for some fsl powerpc stuff
[13:08] <ogra> well, should be only the driver init
[13:09] <persia> I once confused an FSL engineer by demonstrating a redboot provided by FSL that booted from ext2 when told that FSL redboot didn't support ext2.
[13:09] <ogra> USB generally is in uboot
[13:09] <asac> i know
[13:09] <asac> see yourself. support isnt there imo
[13:09] <ogra> yes
[13:09] <ogra> but there is a kernel driver
[13:10] <ogra> most uboot drivers are just based on kernel drivers
[13:10] <persia> ogra: Which means you can port it on saturday ? :)
[13:10] <plars> asac: no, that's why I was wondering if tobin might know
[13:10] <ogra> nah
[13:10] <ogra> i'm no kernel hacker
[13:10] <ogra> but i can take a look :)
[13:11] <asac> plars: i remember that we had working dove images
[13:11] <asac> then at some day you said it broke
[13:11] <ogra> plars, well, according to isotracker tobin didnt test dove at all
[13:14] <ogra> did we have dove for A1 ?
[13:14] <ogra> iirc we didnt
[13:22] <ogra> asac, no go
[13:23] <ogra> still comes up with a MAC of 00:00:00:....
[13:23] <ogra> SIOCSIFFLAGS Cannot assign requested address ... is what ifconfig gives me on ifconfig eth0 up
[13:24] <ogra> i guess we need FSL help here
[13:25]  * ogra hugs his USB NIC
[13:26] <dmart> Hi guys... is there an lp bug in the pixman/NEON issues we were seeing?  This needs tracking, because we may revert to CONFIG_NEON=n by default... which will make the problem appear to be solved even though it's not.
[13:26] <dmart> s/lp bug in/lp bug on/
[13:28] <ogra> dmart, Bug #385553 ??
[13:28] <ubot4> Launchpad bug 385553 in pixman "Integrate NEON optimisations for armel" [Wishlist,Fix released] https://launchpad.net/bugs/385553
[13:29] <ogra> we could recycle that one i assume
[13:29] <asac> ogra: yeah. i assume the code is completely busted
[13:29] <asac> it looked really bad hackish
[13:29] <dmart> What code?
[13:29] <ogra> asac, the fun thing is that it defaults to tftpboot
[13:29] <asac> ogra: the mcx_initialize function
[13:29] <ogra> dmart, different issue :)
[13:29] <asac> dmart: the uboot fec driver has odd stuff
[13:29] <dmart> Oh, right :)
[13:30] <asac> seems they moved to an array approach, but only did so at half of the places
[13:30] <asac> like:
[13:30] <ogra> dmart, seems FEC doesnt get initialized at all when using uboot
[13:30] <asac> 13:48 < asac>         for (i = 0; i < sizeof(fec_info) / sizeof(fec_info[0]); i++) {
[13:30] <asac> and then they use fec_info[i]
[13:30] <asac> is that going to work?
[13:30] <ogra> dmart, leaving us without NIC since the kernel cant figure out a MAC for it
[13:31] <asac> e.i would have expected it to be more like sizeof(struct fec_info_s)
[13:31] <dmart> doesn't look right
[13:31] <asac> it looks completely wrong ;)
[13:31] <ogra> dmart, you boot with an older uboot, right, do you have NIC support on your babbage ?
[13:31] <asac> esepecially since the fec_info array is a constant array
[13:31] <ogra> (we might just be able to roll back to an older patch)
[13:31] <asac> that doesnt grow
[13:31] <asac> it should just be i < 1 ;)(
[13:31] <asac> let me check
[13:31] <persia> Does the NIC work if a MAC is just arbitrarily assigned by userspace later?
[13:32] <dmart> It was on a nettop, and I don't remember whether the network was OK... I didn't check that.
[13:32] <ogra> persia, nope
[13:32] <persia> Ugh.
[13:32] <ogra>  SIOCSIFFLAGS Cannot assign requested address
[13:32] <ogra> no matter what i do
[13:32] <persia> NIC not promiscuous?
[13:32] <ogra> the HW isnt completely up
[13:32] <ogra> we had such issues before with redboot
[13:32] <ogra> in jaunty iirc
[13:34] <asac> ogra: get the new patch from same location
[13:34] <ogra> let me first try something
[13:34]  * ogra issues setenv ethaddr 00:04:9F:00:E8:C2
[13:34] <asac> ogra: the _initialize code doesnt initialize anything without that patch
[13:34] <asac> sizeof(fec_info) / sizeof(fec_info[0]) is probably 0
[13:35] <asac> so no device gets initialized
[13:35] <ogra> yeah
[13:35] <ogra> but uboot reports FEC0 as primary interface
[13:35] <asac> yes
[13:35] <ogra> so it knows its there
[13:35] <asac> ogra: it knows about it, but doesnt initialize it
[13:36] <asac> because the loop isnt entered
[13:36] <ogra> yes, thats why i try to check if initialzing it manually changes a thing
[13:36] <asac> no
[13:36] <asac> you cant initialize it manually
[13:36] <asac> because the code that initializes it does nothing ;)
[13:37] <asac> unless you can run C code at the prompt
[13:37] <asac> at least i would try that patch first ;)
[13:38] <asac> e.g. the drivers vtable isnt filled if it really doesnt go in there
[13:39] <ogra> same patch name ?
[13:39] <asac> yes
[13:39] <asac> hmm. if it knows the name it seems to have happened. but try anyway
[13:40] <plars> ah cool, alternates got added to iso tracker today
[13:41] <asac> yeah
[13:41] <asac> so i think that is probably 1 ;) ... too bad
[13:41] <asac> do you see any other errors ogra ?
[13:42] <ogra> just applying the change ...
[13:42] <ogra> one sec, cdbs-edit-patch isnt the fastest on the babbage :)
[13:43] <asac> ogra: copy the patch in there
[13:43] <asac> ogra: you should use quilt
[13:43] <ogra> asac, the package is 100% cdbs
[13:43] <ogra> and i wont touch quilt if i dont have to
[13:43] <ogra> its the biggest pain in the ass i've encountered after git
[13:43] <asac> just replace the patch then :)
[13:44] <asac> oh wait, then it fails to clean
[13:44] <asac> hmm. quilt doesnt have that problem ;)
[13:45] <asac> ogra: if you are still at it, grab a new version of the patch that enables debugging
[13:45] <persia> CDBS simple-patchsys doesn't have that problem either.
[13:45] <ogra> ARGH!
[13:45] <asac> fact is that simple-patchsys is for the weak ;)
[13:46] <ogra> did you notice there is fec_mxc.c and mxc_fec.c in the drivers dir
[13:46] <ogra> insanity !!!
[13:46] <asac> really. the one i touched at least gets compiled ;)
[13:46]  * asac checks
[13:46] <persia> Well, someone decided that simple-patchsys was the easiest to teach, so lots of interesting packages end up using it.
[13:47] <asac> yes, but for professional development - aka if you really fix bugs and touch code - its inferior ;)
[13:47] <asac> throwing existing patches together is simplest yes
[13:47] <asac> but rebasing patches that dont apply anymore is a mess ;)
[13:47] <ogra> building
[13:47] <persia> Depends on one's viewpoint.  I also like quilt, which makes me a poor candidate as a simple-patchsys apologist :)
[13:47] <ogra> another 20min ...
[13:48] <asac> often there are viewpoints/opinions ... but in this case there are only facts :-P
[13:48] <asac> ogra: make O=debian/build-*/
[13:48] <asac> then debuild -nc
[13:48] <ogra> dpkg-buildpackage -b
[13:49] <ogra> i want a proper package to work with
[13:49] <asac> yeah. thats why it takes 20 instead of 2 minutes
[13:49] <asac> debuild -nc gives you a good package if you just change one patch
[13:51] <asac> ok
[13:51] <asac> me hopes the other fec source isnt used
[13:52] <ogra> me too :)
[13:53] <ogra> but given that the warnings go away after your first fix it doesnt look like
[13:53]  * ogra takes a coffebreak
[13:53] <asac> ogra: i would abort the break. the enabling of debug fails to build
[13:54] <asac> what a bad code :(
[14:23] <ogra> asac, to late to abort it :)
[14:28] <ogra> asac, no change
[14:33] <asac> ogra: so you didnt pick the DEBUG change?
[14:33] <asac> ok
[14:33] <asac> well. then...
[14:33] <ogra> no, i just picked the fec change
[14:33] <asac> i updated that a minute after you picked it ... thats why i am not sure
[14:39] <ogra> oh, bte, we'Re at 152k for .bin
[14:39] <ogra> vs 136k before switching on ext2 and hush
[14:40] <ogra> *btw
[14:43] <dmart> All, for the pixman issue I raised a new bug #507503 (since the current understanding is that it's not really a pixman bug)
[14:43] <ubot4> Launchpad bug 507503 in linux-fsl-imx51 "VFP/NEON state is not preserved around signal handlers, causing state corruption between user processes" [Undecided,New] https://launchpad.net/bugs/507503
[15:08] <ogra> sihg, is there any way to disable DCC offers in xchat ...
[15:08] <ogra> that spam is driving me insane
[15:33] <ogra> NCommander, do you happen to know if there is any way of command substitution in hush shell ?
[15:34] <NCommander> ogra, define command substitution
[15:35] <ogra> files=$(fatls mmc 0:2)
[15:36] <NCommander> ogra, yeah, you set the command you want in a variable and then run it
[15:36] <NCommander> i.e.
[15:36] <NCommander> setenv testcmd fatls mmc 0:2
[15:36] <NCommander> run testcmd
[15:36] <ogra> an that gives me the flie list in the files variable ?
[15:36] <NCommander> ogra, oh, no
[15:36] <ogra> i want a variable i can work with
[15:36] <NCommander> ogra, can't do that unfortantely
[15:36] <ogra> right, thats what i thought
[15:36]  * NCommander notes hush is very limited
[15:37] <ogra> yes, found that :)
[15:37] <dmart> How about:
[15:37] <dmart>  setenv tmp mmcload ${file}
[15:37] <dmart> run tmp
[15:37] <dmart> (hang on, are you still talking about UBoot?)
[15:37] <ogra> yes :)
[15:38] <dmart> Something like the above might work then
[15:38] <ogra> what i want is some way to detect if uimage exists in a partition/dir
[15:38] <ogra> but i have no grep and fatls is pretty noisy
[15:38] <NCommander> ogra, what I did for dove is just try and unconditionally load the boot.scr file
[15:38] <NCommander> ogra, if that fails, then assume the uimage is MIA, and move on
[15:38] <ogra> "fatls mmc 0:2 uimage" unfortunately doesnt work
[15:38] <dmart> That might work
[15:38] <NCommander> I dunno if fatls/ext2ls return an error code
[15:38] <NCommander> ogra, it should work ...
[15:38] <NCommander> That does work on Dove I think
[15:39] <ogra> doesnt here
[15:39] <NCommander> *grummmmmmble*
[15:39] <ogra> BBG U-Boot > fatls mmc 0:2 uimage
[15:39] <ogra> No Fat FS detected
[15:39] <ogra> BBG U-Boot > fatls mmc 0:2
[15:39] <ogra>   3085760   uimage
[15:39] <ogra>   3282905   uinitrd
[15:39] <dmart> ?
[15:39] <ogra> it somehow interprets the last parameter
[15:39] <dmart> Hmmm, not sure I ever tried that
[15:40] <NCommander> ogra, try fatls mmc 0:2 /uimage
[15:40] <dmart> What does help fatload say?
[15:40] <ogra> it says the last param is a directory :P
[15:40] <ogra> BBG U-Boot > fatls mmc 0:2 /
[15:40] <ogra>   3085760   uimage
[15:40] <ogra>   3282905   uinitrd
[15:40] <ogra> so yes, that works
[15:40] <ogra> but i still dont know if uimage exists
[15:40] <ogra> since i cant parse the return value
[15:41] <dmart> What 's the end goal heer?
[15:41] <dmart> s/heer/here/
[15:41] <ogra> i want to loop over all fat and ext2 partitions and find if there is a boot.scr
[15:42] <ogra> if boot.scr and uimage exist i want to load boot.scr and execute it
[15:42] <Sarvatt> hmm arm SIMD fast paths are disabled in the pixman in lucid
[15:42] <NCommander> ogra, look at how I did it on Dove, and rewrite :-)
[15:42] <NCommander> ogra, I only check for boot.scr and not uImage
[15:42] <ogra> boot.scr then should have all env variables needed
[15:42] <dmart> Is there a way only to iterate over partitions that exist, or do we have to be dump and poll everything (slow?)
[15:42] <dmart> argh s/dump/dumb/
[15:42] <NCommander> dmart, the later, but it isn't too bad, only 3-4 seconds on Dove boot time
[15:42] <ogra> for i in 1 2 3 4 5;do if fatls mmc 0:$i;then fatload mmc 0:$i ${loadaddr} uImage; fatload mmc 0:$i ${loadaddr_initrd} uinitrd;fi;done
[15:42] <ogra> dmart, ^^^ that works fine
[15:43] <ogra> and isnt to slow
[15:44] <NCommander> ogra, http://paste.ubuntu.com/356625/
[15:44] <ogra> my point is i want to detect if i'm using a live image or not as the very first thing ... because then i know for sure where what file is
[15:44] <dmart> Can we do something like for ...; do if <script exists>; then <run script>; break; fi; done ?
[15:44] <ogra> dmart, yes
[15:45] <dmart> Then if we hit the script in an early partiton (likely) we don't have to do the whole search
[15:45] <ogra> the prob is <script exists>
[15:45] <dmart> Right
[15:45] <ogra> you can only blindly load
[15:45] <ogra> thats what NCommander does in the pasted script
[15:45] <dmart> What about mfill will garbage; load script; run script
[15:46] <NCommander> ogra, we could extend u-boot and give it more of a brain
[15:46] <dmart> If no script was loaded, the memory will still be garbage with no headers and the next command will be run.
[15:46] <ogra> NCommander, i just added 20k to the babbage one, i dont want it to grow to big
[15:46] <ogra> also i'm probably to cautious, NCommander's way works ...
[15:47] <NCommander> ogra, u-boot is frustatingly limited in places you don't want it to be
[15:47] <ogra> yes
[15:47]  * NCommander isn't super happy with the code itself, but it does get the job done.
[15:47] <ogra> right
[15:47] <ogra> and i only have mmc atm ... so it would be a lot smalled for me anyway
[15:48] <ogra> *smaller
[15:48] <dmart> Is there some way we can push the complexity out of the bootloader scripting?  Maybe saving things in the U-Boot environment area?
[15:48] <ogra> thats what boot.scr is for
[15:48] <ogra> for babbage i'll just set the right defaults
[15:49] <dmart> Maybe it would be easier just to implement the search in C after all, though I guess that's a last resort.
[15:49] <ogra> boot.scr will then contain loadaddr and cmdline as well as the lioad and bootm commands to get kernel and initramfs
[15:50] <ogra> the loop script will live in the bootloader defaults, boot.scr should only be a few lines for the above
[15:50] <NCommander> dmart, well, the boot.scr mechanism was a last minute hack to have a sane boot on dove
[15:50] <ogra> the important part here is that you dont need serial access, just edit boot.scr and run mkimage on it
[15:51] <dmart> Sure; I was using the same approach when playing with the nettops
[15:52] <ogra> but boot.scr should be limited to the bare minimum
[15:52] <ogra> and uboot should still work if you put it into flash
[15:52] <ogra> so i need to find the right level of complexity for either side :)
[15:53] <dmart> I just thought that if the U-Boot shell isn't up to implementing the search for boot.scr, you could put C into U-Boot to do it instead.  But only if we really can't avoid the complexity.
[15:54] <ogra> well, for i in 1 2 3 4 5;do if fatls mmc 0:$i;then fatload mmc 0:$i ${loadaddr_script} boot.scr;autoscr ${loadaddr_script};fi;done
[15:54] <ogra> thats not to complex
[15:54] <ogra> it gets more complex if i start to look for /casper though
[15:55] <ogra> i guess i could even drop the fatls
[15:55] <ogra> for i in 1 2 3 4 5;do if fatload mmc 0:$i ${loadaddr_script} boot.scr;autoscr ${loadaddr_script};fi;done
[15:56] <NCommander> dmart, well, its probably easier to extend the commands we need
[15:57] <dmart> Maybe... just a thought
[15:57] <ogra> i wonder if $i is still respected if i do setenv myloadscript 'fatload mmc 0:$i ${loadaddr_script} boot.scr'
[15:57] <ogra> then i'd end up with: for i in 1 2 3 4 5; do if run myloadscript; autoscr ${loadaddr_script};fi;done
[15:58]  * ogra tries that
[16:00] <ogra> hmm, no, it doesnt take $i
[16:03] <ogra> HA !
[16:04] <ogra> setenv myloadscript 'fatload mmc 0:$i ${loadaddr} uImage'
[16:04] <ogra> for i in 1 2 3 4 5;do run myloadscript;done
[16:04] <ogra> thats works fine
[16:04] <NCommander> ogra, neat. Isn't the lack of documentation on how this all supposed to work semi-annoying? :-/
[16:05] <ogra> yeah
[16:15] <ogra> http://paste.ubuntu.com/356637/ seems to work fine
[16:19] <asac> ogra: we never look at mmc 1:* ?
[16:19] <ogra> do you want me to ?
[16:19] <asac> not sure if that makes any practical sense
[16:19] <asac> atm probably not
[16:19] <asac> but who knows ;) ... in theory we want to check all devices that are available
[16:19] <ogra> right, i think the babbage can only boot from 0
[16:20] <asac> that includes mmc, usb
[16:20] <ogra> indeed
[16:20] <asac> yeah. but 1 doesnt appear.
[16:20] <asac> so in case something supports 1 it would just work.
[16:20] <ogra> but there is only one mmc and no usb :)
[16:20] <asac> your decision ;)
[16:20] <ogra> we can modify
[16:20] <ogra> i want a case for now where /casper and / both work
[16:20] <asac> i think it wouldnt hurt ... but sure, better work on the directory thing
[16:20] <ogra> and / being preferred, casper being second choice
[16:21] <asac> yeah
[16:21] <asac> ogra: how do we do the root=?
[16:21] <ogra> from boot.scr
[16:21] <asac> maybe we shoudl really go for boot.scr directly
[16:21] <ogra> i'm not at that point yet
[16:21] <asac> ah ok. so we do that in first iteration ;)
[16:21] <asac> hehe
[16:22] <ogra> right
[16:22] <asac> fine
[16:22] <ogra> i'm only playing with the shell capabilities atm
[16:22] <asac> everything works ;)
[16:25] <ogra> gah ... i winder why it hangs now ... silly me
[16:25]  * ogra forgot mmcinfo
[16:27] <asac> which is kind of dubious ;)
[16:27] <asac> what thats needed
[16:27] <asac> maybe we can fix that to run lazily on demand
[16:27] <ogra> as default i'D say
[16:28] <ogra> http://paste.ubuntu.com/356641/
[16:28] <ogra> :D
[16:29] <ogra> god
[16:29] <ogra> is anyone else getting tons of DCC offers today ?
[16:29] <ogra> my screen gets spammed all the time here
[16:32] <asac> dmart: ok
[16:32] <asac> ready ;)?
[16:32] <asac> seems like some good guy entered most rdepends ;)
[16:32] <asac> hmm ... thats bad
[16:33] <asac> good bye
[16:34] <ogra> heh
[16:34] <ogra> you scared him
[16:36] <asac> we had a date
[16:36] <asac> ;)
[16:37] <ogra> itym "an appointment"
[16:37] <ogra> *g*
[16:37] <asac> yep
[16:37] <plars> alternates seem to be failing in several places, sounds similar to what NCommander was describing I think (this is on dove atm)
[16:37] <ogra> unless you planned to bring roses :)
[16:37] <asac> that was the joke ;)
[16:37] <asac> plars: NCommander said they work (probably imx)
[16:37] <NCommander> plars, I was able to get a completed install on dove, but its very twichy
[16:38] <plars> NCommander: I get an error installing the base system (debootstrap warning) that there was an error configuring packages (continue seemed to work ok)
[16:38] <plars> NCommander: then at the end, the "select and install software" step fails and takes me to the menu
[16:38] <plars> NCommander: is that what you saw as well?
[16:38] <ogra> plars, whats the build date ?
[16:38] <NCommander> plars, it depends on the build. Tuesdays build worked without issue except I had to repeat the select a& install software phase
[16:38] <plars> ogra: it's the current one, just synced it this morning
[16:39] <ogra> debootstrap not finishing is bad and usually indicates that something was out of sync when the image was rolled
[16:39] <plars> ogra: 14.1
[16:40] <asac> repeat select and install? strange that it started working on second attempt
[16:40] <ogra> oh, how do you set something to "started" on the tracker
[16:40] <asac> maybe apt cache isnt updated in first run
[16:40] <plars> ogra: new feature :)
[16:40] <asac> ogra: you can say INPROGRESS
[16:40] <ogra> yeah, intresting :)
[16:41] <plars> ogra: it's another option besides pass or fail
[16:41] <ogra> asac, on the isotracker ?
[16:41] <asac> ogra: but thats voluntarily and doesnt show up on the graphs
[16:41] <asac> ogra: ah ... no. i think thats not wanted
[16:41] <ogra> oh, right, i see it in my list :)
[16:41] <asac> as folks might start ... dont submit and others think its well covered
[16:41] <ogra> yeah,m its an odd feature
[16:41] <asac> they really added that?
[16:41] <ogra> yes
[16:41] <ogra> http://iso.qa.ubuntu.com/qatracker/result/3575/385
[16:41]  * asac should have stayed more in touch with QA team
[16:42] <ogra> its adds a little clock next to the tester too
[16:42] <asac> ok. that was discussed as a potential way, show it for 1-2 hours
[16:42] <ogra> Result : *	Passed Failed Started
[16:42] <asac> dmart: welcome back ;)
[16:42] <plars> asac: that was discussed, but it doesn't prevent others from doing the test, and also it time/datestamps when someone flagged it as 'started'
[16:42] <ogra> dmart, he has roses for you he said :P
[16:42] <plars> asac: so if they flagged it yesterday, you can assume they hit a roadblock, or something is preventing them from completing
[16:42] <dmart> hmmm
[16:43] <dmart> IRC troubles
[16:43] <dmart> asac, did you want to carry on with the package list review
[16:43] <plars> asac: the other side of this is that some things have quite a few tests that need to get run, and it's more efficient if people can flag tests as something they are working on, so that others can seek coverage of the other tests first
[16:43] <asac> dmart: that was the idea. we can do that tomorrow at 10 UTC if you want
[16:44] <asac> yeah
[16:44] <dmart> asac: Now should be OK for a bit. IRC seems to be working again for me
[16:44] <plars> better to have one person testing each thing in parallel, than 10 people testing the same thing when time is short
[16:44] <asac> plars: yeah true. i always was optimistic that we could motivate a big crowd of testers
[16:46] <dmart> Has anyone else experienced possible Ethernet autonegotiation issues with Babbage boards attached to hubs?
[16:47] <ogra> dmart, only poweroff issues
[16:47] <ogra> and only on the B2.0
[16:48] <asac> dmart: ok lets get started if you want
[16:48] <asac> had to get the files first again
[16:48] <dmart> ogra, we can pursue that later
[16:48] <dmart> asac: OK
[16:48] <asac> https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList
[16:48] <asac> gmp
[16:48] <asac> is where we stopped it seems
[16:49] <asac> uses mov ...
[16:49] <dmart> ogra, can you point me to something that explains what rootstock is?
[16:49] <ogra> hmm
[16:50] <ogra> https://wiki.ubuntu.com/ARM/RootfsFromScratch isnt enough ?
[16:50] <asac> gnome-pilot
[16:50] <dmart> asac: add     r2, pc, #invtab-.-8: looks like it assumes ARM and needs looking at
[16:50] <ogra> https://launchpad.net/project-rootstock/ has some explaining text at the top
[16:51] <lool> ogra: Did you manage to merge the rootstock branches yesterday?
[16:51] <asac> false positive
[16:51] <asac> dmart: gmp?
[16:51] <ogra> lool, sorry, no, doing that now
[16:51] <asac> ok
[16:51] <asac> updated
[16:51] <asac> gnome-pilot is false positive
[16:51] <dmart> ogra, I have a cryptic email question I need to answer... I think I'm OK, I'll come back if I need anything extra.
[16:52] <asac> graphviz:
[16:52] <dmart> asac: yes
[16:52] <asac> also false-posiitive
[16:52] <asac> same for installation-guide ;)
[16:52] <asac> good
[16:53] <asac> libatomic-ops  and liffi are next
[16:53] <dmart> darn... variables called "strex" :P
[16:53]  * asac wonders if atomic-ops should already have the right code
[16:54] <ogra> lool, merged and pushed
[16:54] <ogra> lool, sorry for the delay
[16:56] <ogra> oh, you split the work on two branches ...
[16:57] <asac> dmart: libffi already has the bx ... agree?
[16:57] <dmart> libatomic-ops needs a review for SMP safety and memory barriers.  It looks like the existing code was written against ARMv6 so it might not have everything we need.
[16:57] <asac> hmm.
[16:57] <asac> ok lets mark for review
[16:58] <ogra> lool, second one merged as well
[16:58] <asac> dmart: http://paste.ubuntu.com/356654/ thats what libffi does imo
[16:59] <dmart> asac: if that's the only hit in libffi it looks OK
[16:59] <asac> i think so:
[16:59] <asac> search-arm-mov.filt: ./libffi-3.0.9~rc3/src/arm/sysv.S:# define call_reg(x)	mov	lr, pc ; bx	x
[16:59] <asac> search-arm-mov.filt: ./libffi-3.0.9~rc3/src/arm/sysv.S:# define call_reg(x)	mov	lr, pc ; mov	pc, x
[16:59] <asac> search-arm-mov.filt: ./libffi-3.0.9~rc3/src/avr32/sysv.S:    mov     pc, lr
[16:59] <asac> those are the hits
[17:00] <asac> libgc: false-+
[17:00] <dmart> Are you sure:   __asm__ __volatile__("swp %0, %2, [%3]"
[17:01] <asac> hmm
[17:01] <asac> let me grep again
[17:02] <asac> you are right
[17:02] <asac> i am on crack ;)
[17:02] <asac> i grepped for two in a row and looked at libgd-gd2-perl
[17:02] <dmart> AH
[17:02] <dmart> (sorry, caps lock)
[17:03] <asac> libgd2 -> false+
[17:03] <dmart> yes, looks like it
[17:03] <dmart> (both libgd2 and libgd-gd2-perl)
[17:03] <asac> search-arm-mov.filt: ./libmad-0.15.1b/imdct_l_arm.S:    add     r2, pc, #(imdct36_long_karray-.-8)  @ r2 = base address of Knn array (PIC safe ?)
[17:03] <asac> libmad
[17:03] <asac> tha tis
[17:05] <dmart> Simililar to gmp, it looks like it assumes ARM and needs a closer look
[17:06] <asac> libpst:
[17:06] <dmart> false-+
[17:06] <dmart> I think
[17:06] <asac> yeh
[17:06] <dmart> Same for libwoodstox
[17:06] <asac> libwoodstock-java hopefulyl too
[17:06] <asac> checking
[17:07] <dmart> I think we can ignore linux-*: this is for the kernel maintainers.
[17:07] <asac> linux -> not covered
[17:07] <asac> yeah
[17:07] <asac> filling that up
[17:08] <asac> llvm
[17:08] <dmart> linux86: is separate: it's an x86 assembler, so false-+
[17:08] <asac> ./llvm-2.6/test/CodeGen/ARM/2009-05-18-InlineAsmMem.ll:	%asmtmp = call i32 asm sideeffect "swp $0, $2, $3", "=&r,=*m,r,*m,~{memory}"(i32* %p, i32 %i, i32* %p) nounwind
[17:08] <lool> ogra: thanks
[17:08] <asac> yeah i marked all linux* as not covered
[17:09] <asac> hmm. llvm-gcc isnt in the table
[17:09] <asac> only llvm. did you treat them as one dmart ?
[17:10] <dmart> llvm looks like it needs a closer review.  There are things called Thumb2, bx etc.  But it also uses swp and not ldrex/strex
[17:10] <dmart> What is llvm-gcc?
[17:11] <asac> one sec
[17:11] <asac> Meizirkki: grepping for llvm gives things like:
[17:11] <asac> dmart: ^^
[17:11] <asac> search-arm-mov.filt: ./llvm-gcc-4.2-2.6~pre1/llvm-gcc-4.2-2.6/gcc/config/arm/thumb2.md:     to add.w r8, pc, #0, not addw r8, pc, #0.  */
[17:12] <asac> llvm-gcc isnt in the table afaics ... adding
[17:12] <dmart> Ah... it's in universe
[17:12] <dmart> scroll down
[17:12] <asac> really? i scrolled down
[17:12] <asac> ok
[17:12] <asac> missed it most likely
[17:13] <asac> ok mono is next
[17:13] <asac> needs investigation. they use atomic stuff
[17:13] <dmart> Yes, plus "mov pc, lr" type stuff which might not work in Thumb-2.
[17:14] <plars> interesting, with alternate the behavior is different.  Gdm comes up and seems to respawn continuously a few times before dropping out to a text mode login (at which point the system is hung).  Still not having any luck getting kernel output over serial even in this state though
[17:14] <dmart> nasm - false-+ (another x86 assembler)
[17:14] <asac> dmart: nasm is marked as x86 only in the table
[17:14] <asac> yeah
[17:14] <asac> ncurses
[17:14] <plars> but I do see that ureadahead and plymouth seem to be having problems
[17:14] <asac> luckly false+
[17:15] <asac> newlib
[17:15] <dmart> not sure; do we know what uses it?
[17:15] <asac> -> investigate mov's
[17:15] <asac> hmm
[17:16] <asac> newlib is mared as having 0 rdepends
[17:16]  * asac wonders if that is true
[17:16] <asac> runtime depends 0
[17:16] <asac> on libnewlib0
[17:17] <dmart> May not be a priority then.  Since this is an alternate libc implementation, it would be a bit odd to see things using it... ?
[17:17] <asac> yeah. i added "investigate if its used"
[17:17] <asac> ocaml
[17:18] <dmart> newlib - It looks like the affected code is on places like crt0.S where it may not be a problem.
[17:18] <asac> hmm ok
[17:18] <asac> ill add that comment
[17:19] <dmart> ocaml - I guess that needs a look.
[17:19] <asac> yeah
[17:19] <asac> seems jocaml uses a code copy
[17:20] <asac> openbabl doesnt even have a a hit for me
[17:20] <asac> oh
[17:20] <asac> openbabel ;)
[17:21] <asac> search-arm-swp.filt: ./openbabel-2.2.3/src/formats/inchi102/ikey_base26.c:"SWM","SWN","SWO","SWP","SWQ","SWR","SWS","SWT","SWU","SWV","SWW","SWX","SWY","SWZ","SXA","SXB",
[17:21] <asac> that doesnt look like asm
[17:21] <asac> openjdk-6 needs a loog -> doko
[17:22] <asac> openssl seems ok
[17:22] <asac> only armv4 source files affected
[17:22] <asac> pho:
[17:22] <asac> php:
[17:22] <dmart> openbabel - agreed
[17:22] <dmart> openjdk-6 - agreed
[17:23] <asac> false+ (php5)
[17:23] <asac> pixman ...
[17:23] <dmart> openssl - someone should take a quick look to make sure the armv4 files are not still used when building for newer arches
[17:24] <asac> hmm. you are tough ;)
[17:24] <asac> we already have enough work :-P
[17:24] <asac> but ok
[17:24] <dmart> Hopefully that's a quick check...
[17:24] <asac> search-arm-mov.filt: ./pixman-0.16.2/pixman/pixman-arm-detect-win32.asm:    mov pc,lr
[17:24] <asac> yeah
[17:24] <asac> that one probably needs to be checked
[17:25] <asac> though i would hope we can ignore win32 ;)
[17:25] <dmart> pixman should be a quick review too, since that's being actively maintained
[17:25] <dmart> php5 - agreed false-+
[17:25] <asac> postgresql -> the atomic thing is fixed in bzr ...
[17:26] <asac> yes
[17:26] <dmart> GCC atomics?
[17:26] <asac> yes
[17:26] <dmart> cool
[17:27] <dmart> procps - false=+
[17:27] <dmart> ps3-kboot - not relevant (bootloader)
[17:27] <dmart> pulseaudio - should be checked for SMP-safety
[17:28] <dmart> (maybe port to atomics)
[17:29] <asac> python is owned by doko ;)
[17:29] <ogra> he
[17:29] <ogra> e
[17:29] <ogra> h
[17:29] <asac> but i think they use the same macros
[17:29] <asac> for call_reg
[17:29] <asac> so its probably ok
[17:30] <asac> but i will note those as to chcek by doko
[17:30] <asac> qemu-kvm
[17:30] <dmart> Yep.  Looks like it may be OK, but worth a check.
[17:30] <dmart> (python*, that is)
[17:31] <ogra> qemu-kvm is a mess anyway wrt nonn x86 compatible binaries
[17:31] <asac> not sure what to do with qemu
[17:31] <ogra> nothing
[17:31] <ogra> it should go into PAS since ages
[17:31] <asac> i think i will note down that lool checks that ;)
[17:31] <asac> ogra: we look at the asm code ;)
[17:32] <ogra> yes, but if you dont buiuld for != x86 who cares ?
[17:32] <asac> qt-x11-free
[17:32] <dmart> qemu has a swp-based atomic which can hopefully be ported to GCC atomics.  The rest looks like disassembler code.
[17:32] <asac> ok adding that
[17:33] <asac> search-arm-mov.filt: ./qt-x11-free-3.3.8-b/src/3rdparty/libpng/pngvcrd.c:         mov pctemp, eax       // save pc for later use
[17:33] <dmart> false-+? (looks like x86 asm)
[17:33] <asac> yeah
[17:34] <asac> wow
[17:34] <asac> qt4-x11 has a webkit copy :(
[17:34] <dmart> Ugh
[17:34] <asac> needs to be checked, but if they have a recent snapshot it should be as ok as chromium (which we dont know for sure)
[17:34] <dmart> Also, I'd alread raised a bug #490371
[17:34] <ubot4> Launchpad bug 490371 in qt4-x11 "Atomic operations not safe for ARMv7,Thumb-2 and multicore" [Medium,Triaged] https://launchpad.net/bugs/490371
[17:35] <asac> i think its safe to ignore reboot-imx ... thats most likely build for arm5
[17:35] <asac> ogra: ?
[17:35] <ogra> yes
[17:35] <lool> (I dont think qemu is that arch-specific; it might fail to build or be incomplete, but it's certainly a workable concept for any arch on any arch so it should not be listed in PaS IMO)
[17:35] <asac> dmart: thanks. noting
[17:35] <dmart> redboot - agreed: bootloaders don't run SMP, and we'd already know if it didn't work on imx51 ;)
[17:35] <ogra> lool, i know ... we had that discussion before :)
[17:35] <lool> https://buildd.debian.org/build.php?arch=&pkg=qemu speaks for itself
[17:36] <asac> sg3-utils
[17:36] <asac> search-arm-swp.filt: ./sg3-utils-1.28/src/sginfo.c:    bitfield(pagestart + 10, "SWP", 1, 2);
[17:36] <asac> hmm
[17:36] <dmart> false-+ ?
[17:36] <asac> lets hope
[17:36] <asac> swig1.3
[17:36] <asac> same
[17:36] <dmart> YES
[17:37] <dmart> argh... "yes"
[17:37] <asac> syslinux -> ignore
[17:37] <dmart> agreed
[17:37] <asac> texlive-bin
[17:37] <asac> x86
[17:38] <asac> thunderbird -> covered by firefox
[17:38] <dmart> Also false-+.  I'm surprised how often strex is appearing as a variable name...
[17:38] <dmart> (texlive-bin, I mean)
[17:38] <asac> though we might need xulrunner 1.9.2 backport as tbird 3.0 uses 1.9.1 afaik
[17:38] <asac> unles 3.1 comes out soonish
[17:38] <asac> dmart: texlive-bin is also x86 asm
[17:38] <dmart> If the xptcall stuff shared then... will bug fixes propagate?
[17:39] <asac> ok just a couple left ;)
[17:39] <dmart> texlive-bin - oh, right
[17:39] <asac> dmart: yes
[17:39] <asac> they use a xulrunner copy (unmodified)
[17:39] <asac> unzip
[17:39] <asac> acorn ... does that apply?
[17:40] <dmart> Umm, probably not. It looks like very old, possibly pre-ARMv3 code.
[17:40] <asac> yeah. just curious if someone would keep acorn name
[17:40] <asac> lest assume so
[17:40] <dmart> I'll take a quick look but we can probably ignore
[17:40] <asac> upx-ucl
[17:40] <asac> needs a look ;)
[17:41] <asac> vim
[17:41] <asac> search-arm-mov.filt: ./vim-7.2.245/src/swis.s:movspc,lk
[17:41] <dmart> upx-ucl: probably. What is this package?
[17:41] <asac> no ide ;)
[17:42] <asac> for webkit we already know we want to check
[17:42] <asac> xen -> ignore ?
[17:42] <asac> xine-lib i dont know.. please check
[17:43] <asac> zip is last:
[17:43] <dmart> "UPX is an advanced executable file compressor", apparently
[17:43] <ogra> another zipper :)
[17:43] <dmart> xen is probably out of scope right  now
[17:43] <asac> also acorn ;)
[17:43] <asac> yeah... xen isnt working at all afaik
[17:43]  * ogra would put it under "linux"
[17:43] <asac> so vim and xine-lib are the last too
[17:44] <dmart> vim - hold on, I'll take a look; probably not relevant.
[17:45] <dmart> zip, unzip: the matches are in old RiscOS code which as ARM assembler syntax and can't be processed by GNU as anyway. We can ignore these.
[17:45] <asac> yeah. so i saved the wiki. xine-lib is last to fill in in main ;)
[17:45] <asac> well done!
[17:46] <asac> now someone needs to file bugs ;)
[17:46] <asac> or first fix wiki syntax ... doing that
[17:46] <asac> ok done
[17:46] <asac> lets continue later ... have to run to a call :)
[17:47] <dmart> I will probably disappear now... catch you tomorrow
[17:47] <dmart> Thanks
[17:47] <asac> sure
[17:47] <asac> enjoy
[17:48] <ogra> dinner !!!
[17:48] <ogra> see^Whear you at the call
[17:54] <dmart> bye guys
[19:01] <NCommander> plars, alternate installer passed on dove
[19:01] <NCommander> (very slow)
[19:02] <plars> NCommander: did for me too, but fails to come up correctly (same bug with X we saw on desktop)
[19:02] <plars> NCommander: you didn't have to retry a lot?
[19:02] <plars> well, not a lot
[19:02] <plars> just twice really
[19:03] <plars> once continue because it failed debootstrap attempt configuring  base packages
[19:03] <plars> then again when select and install software step failed, had to go back to the menu and retry that (which worked it seems)
[19:04] <plars> imx51 one seems to be completely stuck here, and I don't see a way out
[19:04] <plars> not hung at least
[19:04] <NCommander> plars, checks vty4
[19:05] <plars> right, I have unpacking openoffice.org-common
[19:06] <plars> for the last 1+ hours
[19:12] <plars> NCommander: not seeing anything useful in syslog, is there a debug mode with alternates?
[19:12] <NCommander> plars, /var/log/installer.log
[19:13] <plars> NCommander: nope
[19:13] <plars> NCommander: syslog, media-info, and partman are the only logs there
[20:36] <asac> plars: "You can get the chip rev in the kernel with cpu_is_mx51_rev() or looking at /proc/cpuinfo system rev value. The encoding is <chip num><board
[20:36] <asac> +rev><chip rev>"
[20:36] <asac> plars: tugess you already knew that (for system information /test)
[20:36] <asac> guess
[20:36] <plars> asac: I'm already gathering /proc/cpuinfo
[20:37] <plars> asac: ideally, I'd like to know the uboot version in flash, and the firmware version (but no bios, so not much chance of that I suspect)
[20:37] <asac> yeah
[20:37] <asac> i know
[20:37] <asac> yeah.
[20:38] <plars> only thing would be if it could be communicated down from uboot through a boot param... but I think that might be overkill just to gather a bit of extra info like this
[20:38] <asac> yes. thats what i suggested too
[20:38] <asac> for now
[20:38] <asac> depends on how important that info is
[20:39] <plars> asac: it's nice to have, but can be gathered other ways
[20:39] <asac> just wonder whta use it would be, most likely if uboot is the problem, the system doesnt boot at all
[20:39] <asac> so you cant gather that that easily
[20:42] <asac> plars: for you bug 495171 is gone, right?
[20:42] <ubot4> Launchpad bug 495171 in linux-fsl-imx51 "USB errors while installing" [Undecided,New] https://launchpad.net/bugs/495171
[20:43] <plars> asac: correct, I am no longer seeing that one
[20:43] <asac> ok i will close it then
[20:43] <asac> done
[20:43] <asac> ;)
[20:44] <asac> actually ... now that i look at it, it looks exactly like the issues i get when trying use my usb-storage thing
[20:44] <RaffoPazzo> hi. i have a little question for you. Is there a way i can find ubuntu packages compiled with optimization for my cortex-a8 architecture ? Like, for example, neon extension enabled.
[20:44] <asac> guess i should rather open a new bug if your hardware doesnt have that
[20:45] <RaffoPazzo> i don't think that the packages available by rootstock are optimized...
[20:45] <RaffoPazzo> i'm i wrong ?
[20:45] <asac> in general we dont optimize for neon, some packages use hwcaps though to use optimized code
[20:45] <asac> dont ask me which ;)
[20:48] <RaffoPazzo> yes, for example there is a xserver video dirver specific for omap3, so using neon and this is good, so x would be faster
[20:48] <asac> plars: have you tried to fix dove  by using an older kernel?
[20:48] <asac> NCommander: ^^?
[20:48] <RaffoPazzo> but i guess i should use gentoo if i want everything optimized....and i would not..roostock is so useful ^^
[20:49] <asac> NCommander: https://edge.launchpad.net/ubuntu/+source/linux-mvl-dove/2.6.31-701.4
[20:49] <asac> that one i guess
[20:49] <armin76> :D
[20:49] <asac> oh
[20:49] <asac> https://edge.launchpad.net/ubuntu/+source/linux-mvl-dove/2.6.31-701.3
[20:49] <asac> that one NCommander ^^
[20:50] <plars> asac: that kernel has been out for about 4 weeks.  However there was some speculation by ncommander I think, that some of the thumb2 rebuilding could be the cause of the breakage
[20:50] <RaffoPazzo> is theere a way i can see on which architecture a package was compiled on ?
[20:51] <armin76> RaffoPazzo: lucid is all armv
[20:51] <armin76> 7
[20:51] <RaffoPazzo> tnx
[20:53] <asac> plars: do we know that it worked at some point with that kernel?
[20:53] <asac> given that everyone was on vacation etc. i would say no
[20:53] <plars> asac: right
[20:54] <asac> so before speculating, we should test the kernel ;)
[20:54] <plars> asac: GrueMaster, which was why, I think GrueMaster was going to try some of the images he has archived
[20:54]  * armin76 offers to test the kernel *g*
[20:54] <asac> ok cool
[20:54] <plars> I can try *just* swapping the kernel if needs be though
[20:54] <asac> GrueMaster: what images do you have archived for dove?
[20:55] <asac> plars: that would be good imo
[20:55] <asac> i think we definitly know that we had working images with the kernel before
[20:55] <asac> so if that doesnt fix it, we know at least that the kernel alone isnt busted