#ubuntu-arm 2010-01-11
<pwnguin> lol
<pwnguin> "This is the bug tracker, with mail notifications going to developers who have"
<pwnguin> many things to work on. Please keep the discussion to necessary technical
<pwnguin> details. Refusal to do so may result in termination of your account. We hope
<pwnguin> for your understanding.
<lool> gregoiregentil: Thanks; I had not tested it, will look at fixing the patch to use MOUNTPOINT
<ogra> fresh uboot-imx is uploaded with the lastest patchset ...
<ogra> lool, i could need some expert help with image partitioning .... http://paste.ubuntu.com/354966/ has the script that alex and i worked out for uboot images based on redboot-install, but somehow that results in a vfat partition uboot only reads corrupted data from
<ogra> you probably see something obvious we both dont find
<dmart> Hi there... does anyone know why there were no armel daily-live images for the last couple of days?
<dmart> 20100108 seems to work well, but the more recent images seem to have no armel variants.
<ogra> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ubuntu-imx51/ doesnt indicate that there were any builds
<ogra> not even attempts
<dmart> Is that expected, or did something go wrong?
<dmart> http://cdimages.ubuntu.com/ports/daily-live/ has 20100110 and 20100111, but they only seem to have ia64 and powerpc
<lool> ogra: Does it relate to some other script?
<lool> dmart: That's when the build failed
<lool> Hmm someone dropped the weather report from the topic
<ogra_> sorry reconnect
<lool> Ah perhaps only -mobile had it
<lool> dmart: http://qa.ubuntu.com/reports/ogasawara/weatherreport.html
<ogra_> no hanging procs on the main buildserver
<ogra_> i wonder why there are no buiold attempts then
<lool> dmart: So what it means is that either the ISO or the livefs failed to build
<lool> dmart: livefs http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/
<lool> No log at all   :-/
<dmart> Strange
<ogra_> right, as i said, no attempt
<ogra_> x86 built though ... so the builds were not disabled
<lool> The crons certainly list armel
<ogra_> right
<ADcomp> hello .. I'm happy :) .. Karmic is running fine on my new board ( http://www.technexion.com/index.php/thunderpack )
<ogra_> great to hear
<ADcomp> Can I add this board to "ARM/DeviceSupport" on ubuntu wiki  ?
<lool> ===== Downloading live filesystem images =====
<lool> Mon Jan 11 05:35:27 GMT 2010
<lool> Read error (Connection reset by peer) in headers.
<lool> That's how the CD build fail
<lool> I suspect the livefs builder is down
<ogra> yep
<ogra> i pinged lamont already
<lool> ADcomp: Which kernel tree supports the board?
<lool> ADcomp: Does linux-omap support it?  linux?
<ADcomp> lool: 2.6.31
<lool> ADcomp: You mean naked linux 2.6.31 will support this board?
<ADcomp> lool: compiling this one : https://code.launchpad.net/~beagleboard-kernel/+junk/2.6-stable
<lool> ogra: touch can be dropped at the start of the script
<ogra> thats from linux-omap
<ogra> lool, yeah, i noted that too, alex added it, but thats surely not the issue
<lool> ogra: I'm reading it anyway, so better making comments on all things I see
<lool> UBOOT_SIZE=$(wc -c $UBOOT_BIN |cut -d ' ' -f1) => stat much better
<ogra> i also want to switch to your ingenious way of creating the empty image without time loss
<ADcomp> lool: diff = http://pastebin.com/f60903eb6
<lool> stat -c %s foobar
<ogra> lool, yeah, i havent ported all the functions yet, stat will be used in the next iteration
<ogra> yep
<ogra> the other script has a proper function for it
<lool> ogra: The first partition seems too small to me
<ogra> 142848B
<ogra> ogra@osiris:~/Desktop/uboot$ ls -l uboot-imx51_to3.bin
<ogra> -rwxr-xr-x 1 ogra ogra 142952 2010-01-07 17:20 uboot-imx51_to3.bin
<lool> You changed FIS_SIZE to UBOOT_SIZE, but the FIS starts at offset zero of the disk while UBOOT starts at offset zero of the partition
<ogra> hrm
<ogra> you are right
<lool> You need to add 512 to UBOOT_SIZE - 1
 * ogra slaps forehead ...
<ogra> oh my !
 * ogra blushes 
<ogra> indeed
<ogra> asac, ^^^
<lool> Ah hold on, you actually seek and skip 1024 bytes in UBOOT_BIN
<lool> Where do these 1024 come from?  Is this padded?
<ogra> yes, so it needs to be 1024
<ogra> no
<ogra> could be 512
<asac> well.
<asac> i am sure i did that
<asac> i even aligned it to cluster sizes
<lool> I don't understand what asac is saying; can I get a sample binary?
<asac> like looking what cluster size the real SD card would have and then see that
<ogra> asac, its not the cluster sizes or anything
<ogra> asac, the uboot partition is smaller than uboot itself
<asac> sure. i aligned by 512 ... using integer match
<asac> e.g. so the size was bigger
<asac> but i wont remove the hope. so give it a try ;)
<asac> math
<lool> asac: I'm asking about the 1024 offset in the binary and in the dd output; I don't understand where the 1024 come from if it's not padded
<asac> its padded
<asac> and i had a working uboot image with that ... just tat that partitioning was manually done on the SD before
<asac> i seriously dont know exactly why its there, but it clearly worked here
<ogra> we dont add any extra padding during package build
<ogra> so it should be unpadded
<asac> right. but the .bin itself has probably a MBR at the beginning or something
<lool> So if it's padded, you need to remove 1024 to uboot_size when creating the partition
<ogra> it shouldnt
<asac> feel free to put the full .bin onto it
<lool> What do you use as input?
<asac> lool: remove size? why would a too big partition cause any issues?
<ogra> lool, input ?
<lool> ogra: as input uboot .bin
<lool> asac: It wouldn't be the issue, but it's still wrong
<asac> the uboot-imx51 package
<ogra> the to3.bin from the current uboot-imx51 package
<asac> yeah.
<ogra> and we dont pad it during build, i dont think it gets padded upstream, so there should be no padding at all
<asac> ogra: can you pload the DEBUG build?
<asac> or want to wait f you find something here?
<ogra> gimme some time, i will upoload it with the rest of the default config changes later today
<lool> I checked and it's padded with 0x400 bytes
<ogra> if we get the image going i'd like to add all changes in one go
<asac> yes, so skipping 1024 makes sense
<lool> Yes
<ogra> +ok, thats 1024
<ogra> -+
<lool> Unless the first 4 bytes are a jump or something 'b601 00ea' not sure
<lool> Certainly the next 1020 bytes are zeroes, so I'm tempted to think it's padded
<ogra> intresting, that must come from upistream then
<asac> most likely for if you load it into flash or something
<lool> Stupid openid prevents me from using my editor on the paste stuff
<asac> yes
<asac> thats annoying
<asac> i want openid to go away for past.ubnutu.com
<asac> you cannot even wget the "download " link anymore
<lool> asac: Exactly
<lool> Not even with w3m which I think might actually process javascript; you hit a Continue button
<asac> i complained now
<ogra> just FYI, clementine needs a powercycle
<ogra> dmart, ^^^ the builder hangs
<lool> Is the script kept in bzr somewhere?
<ogra> lool, not yet
<lool> Can I patch it in place and send you the new version?
<ogra> we're in very early stages
<asac> ogra was too lazy for that ... so we used pastebin ;)
<ogra> yeah
<asac> sorry
<ogra> me ?!?
<ogra> bah
 * ogra throws a snowball at asac
<asac> yes, you are the owner, so you are supposed to do that in bzr :)
<lool> I don't know whom
<asac> i am just the peer poking you
<ogra> pfft
<dmart> For the 1024 bytes padding issue in U-Boot, I think the on-SoC low-level bootloader ignores the first K and executes the bootloader binary from offset 1024 in the boot device.  This seems to apply to RedBoot and U-Boot (I've successfully booted U-Boot this way at my end)
<dmart> It has nothing to do with any notional block size on the device AFAUK
<dmart> (afaik)
<lool> dmart: Agreed; we're just trying to get the math right
<lool> We're not writing the full image to disk as it would erase the partition table
<ogra> dmart, yes, i'm just wondering what adds the padiing, in redboot we add it during package build iirc, while we dont do that in the uboot build
<lool> ogra: God
<dmart> Dunno there.  The U-Boot build process may add it.
<lool> You copied the PART1_ID_OFFSET="$(hex2dec 0x1c2)"
<lool> That's probably the issue
<asac> it must be something before uboot
<lool> Oh no that's always correct
<lool> Nevermind  :)
<ogra> right
<ogra> i checked that manually
<asac> ogra: i found a bug in that
<lool> I thought it was the offset of the data, not in the partition table
<asac> but that didnt change a thing
<asac> ogra: with sh the data fs partition string dding breaks
<asac> you have to wrap it with bash -c "..."
<asac> otherwise that printf outputs 3 bytes
<ogra> not here
<asac> and you end up with this odd E.. FS partitoin
<asac> ogra: ppost what you have for fdisk -l
<asac> first partitoin isnt Non-FS data iirc for you
<asac> thats the bug
<ogra> ogra@osiris:~/Desktop/uboot$ fdisk -l test.img |grep test.img1
<ogra> test.img1               1           1         139+  da  Nicht-DS-Daten
<ogra> looks like it should
<asac> strange
<asac> then i dont know whats going on with my dash ;)
<asac> it definitly is broke here
<ogra> its your vanilla kernel breaking it :P
<asac> bah
<lool> I had a check for the size of the partition and there is none here
<asac> none?
<lool> ogra, asac: Do you have a run with debug output of the script?
<asac> what did you try?
<asac> i dont even know which version of the script you are using
<asac> ogra: can you push whatever you currently have to some bzr branch so we have the same baseline ;)?
<lool> asac: I'm not using any; I'm changing the one ogra pinged me with earlier here
<lool> I will give you an updated one fixing the issues I listed
<asac> lool: so ogra gave you a script
<ogra> asac, waiting for what lool will send me and put that in bzr
<asac> ok. getting cigarettes ... hope its there after that
<asac> want to give it a try ;)
<asac> now that the bbg2 works
<ogra> lool, adding the 512 to UBOOT_SIZE doesnt change a thing here
<asac> shenki: anything you needed from me?
<ogra> BBG U-Boot > fatload mmc 0:2 0x90008000 /uimage
<ogra> reading /uimage
<ogra> still hangs there
 * asac out for cigarettes for real now ;)
 * lool pushes lp:~lool/+junk/uboot-image-script
<lool> ogra: I don't have babbage 2, so I can't try the output on a babbage board; I could perhaps run the script but that's the best I can do; I'm still finishing the review, if I don't have any idea, I will ask for the output of the script and the boot output
<ogra> ok
<ogra> UBOOT_SIZE=$(($(stat -c %s "$UBOOT_BIN") - 1024)) ??
<ogra> why do you subtract the padding ?
<ogra> ./uboot-image-script: 67: arithmetic expression: expecting primary: ""62914560" / 1024"
 * ogra checks
<lool> I pushed sanity checks
<lool> ogra: Looks like parted output is bofus
<ogra> ah
<lool> ogra: Could you send a set -x run output?
 * lool goes to lunch and will look at this when coming back
<ogra> will do
<lool> I will add further checks at the end of the script
<ogra> hmm, seems that trashed the uboot binary
<ogra> doesnt get to a prompt
<ogra> lool, http://paste.ubuntu.com/354994/
<ogra> the uboot binary is definately truncated in this version though
<asac> one question i am not sure about: man parted say that mkpart takes [start] [end] .. we seem to pass [start] [size] though. is manpage really wrong?
<ogra> hmm, we should pass [start] [size+start]
<asac> yes
 * ogra will try that but needs some food too now 
<asac> ok repushed lp:~ubuntu-armel/+junk/uboot-image-script
<JamieBennett> asac: Did you talk to lutin about the EFL stuff?
<asac> the inclusion thing? i told him to think about it
<asac> but he didnt like it.
<asac> havent got a final decision yet
<JamieBennett> asac: ah, OK
<dmart> ogra: Just looking at the script...
<dmart> 39: UBOOT_SIZE=$(($(stat -c %s "$UBOOT_BIN") - 1024))
<asac> pushed a few fixes so it works oob here
<dmart> 40: log_run parted -s "$IMAGE" mkpart primary fat32 "512B" "$(($UBOOT_SIZE - 1))B"
<dmart> That makes the partition size = UBOOT_SIZE - 512
<dmart> This is `stat -c %s "$UBOOT_BIN"` - 1536... is the U-Boot binary getting truncated by the fs partition?
<dmart> On line 40, maybe you want UBOOT_SIZE + 512 - 1.
<asac> dmart: pull again
<asac> lp:~ubuntu-armel/+junk/uboot-image-script
<asac> i already ensured that last parameter is END now rather than size
<dmart> Ah, that should work :)
<dmart> (I think)
<ogra> doesnt work here
<ogra> i still end up with a truncated uboot
<asac> tried my branch?
<ogra> yes
<ogra> just zeroed my Sd to make sure its actually using the proper image
<asac> ogra i get uboot promot ;)
<ogra> i dont
<ogra> In:    serial
<ogra> Out:   serial
<ogra> Err:   serial
<ogra> Net:   FEC0 [PRIME]
<ogra> thats it
<ogra> hangs there forever
<asac> In:    serial
<asac> Out:   serial
<asac> Err:   serial
<asac> Net:   FEC0 [PRIME]
<asac> Hit any key to stop autoboot:  0
<asac> BBG U-Boot > mmcinfo
<ogra> even powering off the board doesnt change it
<ogra> whats the imagezize you give on the cmdline ?
<asac> ./uboot-image-script ../out.img ../data/vmlinuz-2.6.31-601-imx51 ../data/uboot-imx51_to3.bin 90M
<ogra> oh, you give it in M
<asac> yes
<asac> its in M ;)
 * ogra tries that
 * asac thinks about building his own uboot on jocote
 * asac has never seen the .bin work there ;)
<asac> are you sure it ever worked?
<asac> ogra: can you create the partitions manually and see if that really helps still?
<ogra> oh damned !!!!
<asac> just want to be sure we are not running after a bad horse
 * ogra durses chromium
<asac> what?
<ogra> *curses even
<asac> heh
<asac> crashed?
<ogra> it created a ton of scripts on my desktop
<ogra> enumerating them
<ogra> instead of overwriting when i download a new version
<ogra> so i copied the same all the time into my workdir :P
<asac> yes
<asac> ogra: use bzr branch ;)
<asac> bzr ftw
 * asac schedules a bzr brain-wash session for sprint
<ogra> heh
<ogra> still not reading uImage though
<asac> yes
<asac> ogra: we need the DEBUG build asap
<asac> we are moving in circles ;)
<asac> maybe we just see whats going on there
 * asac hopes
<ogra> what do you expect to achieve from a DEBUG build beond that it will tell you earlier that the image is corrupted (bad CRC)
<asac> ogra: if you can make a image that works manually, we can dd the partition table and the first few K off and use that rather than parted
<ogra> nah
<ogra> then i'd rather use fdisk scripts
<asac> i want to see details
<asac> we dont see anything atm
<ogra> we do
<ogra> just wait about 20min
<ogra> uboot will restart
<asac> what does that tell you?
<ogra> and will exec the commands over again ... then it shows a bad CRC for the image
<asac> so are you 100% sure that the current .bin works right if you do the part table manually?
<ogra> it worked before, yes
<ogra> i'm still using the one from friday which worked fine
<asac> what partition sizes did you use there?
<ogra> hmm, doesnt seem like uboot for imx has any debug config options at all
<asac> but fat.c etc.
<asac> they want -DDEBUG
<ogra> Number  Start    End        Size       Type     File system  Flags
<ogra>  1      1024B    143359B    142336B    primary
<ogra>  2      143360B  63058431B  62915072B  primary  fat32        lba
<ogra> the first partition is to small
<ogra> ogra@osiris:~/Desktop/uboot$ ls -l uboot-imx51_to3.bin
<ogra> -rwxr-xr-x 1 ogra ogra 142952 2010-01-07 17:20 uboot-imx51_to3.bin
<ogra> 616 bytes to small
<ogra> how did we get there ?
<ogra> err
<ogra> uboot_start=1024 ???
<ogra> why 1024 ?
<lool> ogra: So the /boot partition is miscomputed
<asac> otherwise the script will bail out below
<lool> log_run parted -s "$IMAGE" mkpart primary fat32 "$((${PART1_END_B%B} + 1))B" "${BOOT_SIZE}B"
<asac> maybe that was a bug in first place
<lool> That should be PART1_END + 1 + BOOT_SIZE as second arg
<lool> (end)
<lool> Instead of size
<ogra> yes
<ogra> we use that for redboot though
<asac> lool: is that in latest?
<lool> Also, it's inclusive, so you can substract one
<ogra> i wonder why it doesnt break there
<lool> asac: Dunno, I'm working of my branch
<asac> i thought i made it use end everywhere now
<ogra> asac, 1024 is way to much offset for the start
<asac> the ~ubuntu-armel branch
<asac> i fixed
<lool> Oh
<ogra> asac, 512 for the MBR ...
 * lool merges
<asac> i fixed a bunch ;)
<lool> ogra: 512 for MBR, 512 for part table?
<ogra> err, yes
<asac> mbr has part table included
<ogra> well, 512 for offset :)
<ogra> 1024 leaves a gap
<asac>     die "UBoot partition starts at $PART1_START_B but needs to start at 1024B for the ROM to find the bootloader"
<asac> thats why we needed it
<lool> Hmm actually 512B is enough for both
<ogra> thats nonsense
<asac> so either we need to adjust that or 1024 is ok
<ogra> where did you get that from ?
<asac> good
<lool> asac: Why do you start the partition at 1024B instead of 512B?>
<asac> lets use uboot_start there
<asac> and use that in both places ;)
 * asac commits
<lool> asac: I merged though, you might have to merge now
<ogra>  /me branches this time
<ogra> silly chromium
<asac> done
<lool> -log_run parted -s "$IMAGE" mkpart primary fat32 "512B" "$(($UBOOT_SIZE - 1))B"
<lool> +log_run parted -s "$IMAGE" mkpart primary fat32 "${uboot_start}B" "$(($UBOOT_SIZE - 1 + $uboot_start))B"
<lool> That doesn't make any sense to me
<asac> err. thats bad habit ;)
<asac> anyway
<asac> merging
<lool> asac: Why did you add uboot_start?
<asac> so we can just flit one var now ;)
<lool> asac: Yes but it used to start at 512B, right?
<asac> lool: you added the die check so i fixed the start ... and made a variable out of it
<asac> so now we go back to 512
<asac> ok merge mess finished
<lool> Gah
<lool> uboot_start doesn't mean the same thing now
<lool> UBOOT_SIZE is wrong now
<asac> yes. thats an oversight
<asac> should use the same
<asac> well
<asac> not
<asac> UBOOT_SIZE 1024 is the padding
<asac> the uboot_start is the partition start
<asac> the dd is wrong a bit yes.
<asac> no. no idea what you meant by the die test
<lool> Ok fixed now
<asac> i definitly used thie uboot_start only for partition bits
<lool> I renamed to PART1_START and added a real UBOOT_START if you prefer that
<asac> ok
<asac> whatever works ;)
<asac> lool: thats not good
<asac> "136376 - "1024""
<asac> ./uboot-image-script: 44: arithmetic expression: expecting primary: "136376 - "1024""
 * asac fixes
<asac> done
<ogra>  + 1 - 1 ?
<ogra> why dont you just drop +1
<lool> ogra: To avoid someone adding +1 again  :)  there wasn't any in the first version AFAIR
<lool> That's odd, I didn't know $(()) wasn't doing expansion
<ogra> uboot-image-script/uboot-image-script: 44: arithmetic expression: expecting primary: "142952 - "1024""
<ogra> doesnt change a thing for me
<asac> odd. on bbg2 reset powers off
<asac> ;)
<lool> Yup
<ogra> old bug
<asac> yes. wasnt sure that uboot reset command has same effect
<asac> ericm_: cooloney: hi
<asac> ericm_: cooloney: any update on kernel upload?
<ogra> he mailed the kernel list with a pull request
<ogra> i guess its up to apw to pull and roll now
<asac> ogra: btw, replacing ../out.img with /dev/mmblk0 ... it doesnt help ... isnt that the way you did it?
<asac> cool
<ericm_> asac, marvell patch rebase finished but seems there are many issues with recent lucid
<ogra> not atm, no
<ericm_> asac, will check with NCommander for that
<asac> ogra: how did you create the good partition table?
<ogra> asac, i roll an image and dd it currently ...
<ericm_> asac, I've already sent the status report but would like to hold on for a while til those issues are solved
<ogra> i dont have a good part table atm ...
<asac> ogra: but how did you do it when you had that
<asac> ;)
<asac> ericm_: what issues are those?
<asac> do we have bugs tracking the progress?
<ogra> before i used lool's way of creating an empty image with a 512 byte blocksize and used that value for fdisk -C
<ericm_> asac, gdm or gnome-panel respawned again and again
<ericm_> asac, and X constantly freezes up
<ogra> you should be able to do the same by: fdisk -C $(($(stat -c %s $imagename) / 512)) $imagename
<ogra> or some such
<ericm_> asac, have already checked with Marvell on those issues and no solution yet - I'll ping them more frequently on these
<lool> ogra, asac: Could you test the latest version?
<asac> sure
 * ogra pulls
 * asac dds
 * ogra too
<apw> ogra, what are you waiting for me to do?
<asac> apw: upload imx51
<asac> kernel
<ogra> apw, [Lucid] Git pull request for fsl-imx51 branch upload
<ogra> apw, from kernel-team@
<apw> you are desiring it be the a-2 kernel?  willing to take the pain?
<ogra> apw, we*re waiting for an upload
<ogra> apw, right
<ogra> it has been tested on friday by a bunch of us
<ogra> as long as aufs isnt meesed up it should be a fine kernel for A2
<asac> lool: same issue. hanging on loading uimage
<lool> asac: So this is on B2.0?  Could you paste full boot output?
<ogra> same on 2.5 here
<lool> asac, ogra: I added one more sanity check to verify that the partition is sufficiently big; please repull and rerun (no need to dd to SD card)
<apw> ogra, as you tested it on friday you know its good yes
<asac> lool: http://paste.ubuntu.com/355017/
<asac> seems the sso was removed!!!
<apw> and if its not you can live with it
<ogra> apw, under the assumption that cooloney didnt change anything :)
<lool> asac: SSO?
<asac> signle sign on
<asac> on paste.u.c
<lool> asac: Oh nice
<asac> i ad to add my nick again ;)
<lool> asac: Can you fatls without hanging?
<ogra> lool, http://paste.ubuntu.com/355018/
<ogra> same for me
<asac> lool: yes
<asac> we always could do that
<ogra> right
<asac> which is why i would like to have a uboot DEBUG build
<ogra> only loading doesnt work
<asac> to see whats going on ;)
<lool> Are you guys sure of your load address?  It's not overwriting some important area?
<asac> we had it working
<asac> with good partition table
<asac> but i had a different uboot.bin ... so i rely on ogra saying that his image is good too for that
<lool> Did one of you two re-run the latest version with the check?
<ogra> not yet
<asac> BBG U-Boot > fatls mmc 0:2 3062220   uimage
<asac> 1 file(s), 0 dir(s)
<asac> lool: which version?
<lool> r19
<asac> you mean the script or the uboot.bin?
<lool> script
<asac> yes
<asac> thats what i am trying
<lool> So the test passes?
<asac> hangs on uimage loading
<asac> it didnt fail ;)
<asac> let me double check
<ogra> neither here
<lool> Ok good
<asac> http://paste.ubuntu.com/355025/
<asac> lool: ^
<lool> Well what you guys could do is take your SD, copy the uImage to your PC, re-do the mkfs by hand on the second partition, copy uImage back
<lool> That would rule out mcopy
<ogra> right
 * asac does that
<asac> well i have the uImage here in CWD
<asac> PWD
<asac> so i will just copy that after mounting the SD
<lool> asac: I added code to rm it in the latest version
<asac> heh you remove the uImage now ;)
<asac> sabotage
 * asac recreates
<ogra> hangs here
<ogra> oh, wait, i used the wrong uimage :P
<asac> hangs too
<lool> So I think we need to find a working image again and replace the uboot.bin and the uimage
<asac> i used the right one
<asac> let me check if i really wiped mine
<ogra> hamgs
<ogra> *hangs
<asac> yes
<asac> i have it ;)
<asac> here
<ogra> one sec
<asac> we can dd off the partition table ;)
<ogra> i have a FSL binary
<asac> it works
<asac> http://paste.ubuntu.com/355027/
<asac> but that doesnt use the .bin by ogra
<asac> i had my own in december
<asac> which i used to create that
<lool> I added code to use tempfiles properly
<asac> ok
<lool> asac: Let's replace the .bin then
<ogra> http://people.canonical.com/~ogra/uImage
<asac> lool: then i dont even have that image anymore :)
<lool> asac: ?
<asac> i have it on a SD card only
<lool> I mean copy the working .bin in the non-working image (if it's smaller than ogra's .bin)
<asac> let me see if i can dd it
<asac> i dont have that .bin anymore :(
<asac> it died with the USB harddrive
<ogra> lool, the uboot.bin wors fine
<asac> and i dont know the size anymore
<lool> asac: You could hack our script to have a very large UBOOT partition to be able to dd some MBs of data from your SD to that one
<lool> ogra: Did you ever boot a kernel with the uboot.bin?
<ogra> several
<asac> yes
<ogra> BBG U-Boot > fatload mmc 0:2 0x90008000 /uimage
<ogra> reading /uimage
<ogra> 2211052 bytes read
<asac> we.. i never saw the current .bin working. but i will now manually create the part table etc. and see
<ogra> thats with the fslk uimage
<asac> ogra: so how do you create that part table
<ogra> *FSL
<lool> asac: Add UBOOT_SIZE=$((12 * 1024 * 1024)) after UBOOT_SIZE= in the script and dd 10 MBs of your SD
<asac> can you post that script please
<asac> lool: yes. let me check
<ogra> asac, i used the script
<asac> ogra: so all is fine?
<ogra> no
<ogra> let me try something, one sec
<asac> why did it work for you then?
<ogra> asac, did you use the uImage i just posted ?
<asac> no. i used mine
<asac> e.g. the one created by the script
<asac> a few minutes ago
<lool> I added copyright to the script, since we all work for Canonical, right?  ;)
<asac> you want me to test that?
<lool> (I picked a BSD style header)
<asac> we are supposed to use GPLv3 (not later) ;)
<ogra> ok
<asac> personally fine ;)
<ogra> so
 * asac waits for ogra
<ogra> i create the image which i dd with the script
<ogra> then mount the second partition (leaving nautilus do that)
<ogra> and then just cp the other uImage in place
<asac> ok
<ogra> that seems to work
<asac> odd
<lool> So it would be the uImage?
<asac> how did you produce that?
<lool> lets check the mkimage args
<asac> ogra: ?
<ogra> what ?
<asac> how you produce the uImage that works
<ogra> i dont
<ogra> its a binary FSL offers
<ogra> 2.6.28
<ogra> old kernel
<asac> ok
<ogra> thats why i made us look at mkimage for two days last week
<lool> So with uboot-image-script + FSL uImage, it works?
<ogra> oh, wait !
<ogra> now it hangs
<ogra> lool, no, it doesnt
<ogra> i missed a reformat in the above descriptopn
<asac> ogra: doesnt help
<asac> BBG U-Boot > fatload mmc 0:2 0x90008000 uimage1
<asac> reading uimage1
<asac> hangs
<ogra> i forgot i had run one mkfs.vfat when you asked
<ogra> to rule out mcopy :P
<lool> So uboot-image-script + mkfs + FSL uImage works?
<ogra> right
<lool> What about uboot-image-script + mkfs + our uImage?
<ogra> without mkfs it doesnt
<lool> asac: Could you confirm?
<asac> what mkfs should i run?
<lool> I guess mkdosfs -F32 /dev/sdcard2
<asac> trying
<lool> then write our uImage and FSL uImage and see what you get
<asac> sure
<ogra> ogra@osiris:~/Desktop/uboot$ sudo mkfs.vfat /dev/mmcblk0p2
<ogra> mkfs.vfat 3.0.3 (18 May 2009)
<ogra> ogra@osiris:~/Desktop/uboot$ cp ../uImage /media/37B5-7516/
<asac> got that
<ogra> thats what i do here
<lool> ogra: You used mkfs.vfat?  Could you try mkdosfs -F32 instead?
<lool> So that we can rule out various things in the script
<ogra> will try
<ogra> but the above works definately
<asac> kernel in bad state. thinks its mounted
<ogra> poor you
<ogra> get better HW :)
<asac> sudo mkdosfs /dev/mmcblk0p2
<asac> mkdosfs 3.0.3 (18 May 2009)
<asac> mkdosfs: /dev/mmcblk0p2 contains a mounted file system.
<lool> Probably because of the hang
<lool> asac: dd zero to it first
<asac> ok let me check
<lool> asac: It's a mkdosfs bug I guess
 * asac puts fresh img on sd
<asac> ogra: so what mkdosfs are you running? without F32?
<lool> Right, rewriting the image is enough as well
<asac> didnt help
<ogra> aha !
<asac> its really bad kernel
<asac> rebooting
<lool> That's odd
<ogra> mkdosfs -F32 makes it hang
<asac> ogra: does the trick help withour uimage?
<lool> Cool
<lool> ogra: Try -F16
 * asac checks that
<lool> It's small enough to be FAT16
<lool> I'm pretty sure mkfs.vfat might pick FAT 16 if it's small enough
<lool> If  nothing  is  specified,  mkdosfs  will  automatically select  between  12, 16 and 32 bit.
<lool> From the mkfs.vfat man page
<asac> lool the script is busted
<lool> asac: How so?
<asac> http://paste.ubuntu.com/355033/
<asac> probably your tmp stuff ;)
<ogra> BBG U-Boot > fatload mmc 0:2 0x90008000 /uimage
<ogra> reading /uimage
<ogra> 2211052 bytes read
<ogra> YAY !
<ogra> -F16 FTW
<lool> asac: thanks
<ogra> oh my
<lool> asac: Apparently can;t put the X where I like
<ogra> that costed so much time for nothing
<asac> having double "
<asac> ?
<asac> ogra: we started with F16 not working ;)
<lool> asac: that's fine
<lool> asac: see the mktemp error
<ogra> well, it works
<asac> yeah
 * asac backs it out locally to get something going
 * ogra tries our uImage now
<lool> asac: Fixed and fixed 16 bits too
<asac> good
<lool> And moved the set -e so that mktemp fails the script
<asac> right
<ogra> hmm
<ogra> hangs
<lool> So uImage is next I guess?
<ogra> yeah
<ogra> ogra@osiris:~/Desktop/uboot$ mkimage -l ../uImage
<ogra> Image Name:   Linux-2.6.31-170-ga88b882
<ogra> Created:      Sun Dec  6 23:57:01 2009
<ogra> Image Type:   ARM Linux Kernel Image (uncompressed)
<ogra> Data Size:    2210988 Bytes = 2159.17 kB = 2.11 MB
<ogra> Load Address: 0x90008000
<ogra> Entry Point:  0x90008000
<lool> ogra: You could change UIMAGE to point to FSL uImage in the script and remove the mkimage, that should allow testing the full script with FSL image
<ogra> ogra@osiris:~/Desktop/uboot$ mkimage -l uimage
<ogra> Image Name:   LinuxRocks
<ogra> Created:      Mon Jan 11 15:07:33 2010
<ogra> Image Type:   ARM Linux Kernel Image (uncompressed)
<ogra> Data Size:    3062156 Bytes = 2990.39 kB = 2.92 MB
<ogra> Load Address: 0x90800000
<ogra> Entry Point:  0x90800000
<ogra> oh
<ogra> the adresses differ
<lool> Not the same kernel though
<asac> on my other image it doesnt matter
<asac> what you put on the load address etc.
<lool> Tss someone got the address wrong   ;)
<asac> its all the fatload
<lool> asac: What do you mean?
<lool> asac: if the address is wrong or the kernel differ, you might erase important memory or use a different code path in uboot
<asac> the uImage works perfect on my SD that has my hadcrafted stuff
<lool> e.g. if the kernel is bigger or the address different, it could erase other memory
<lool> Also the kernel boot stuff might have changed across the versions
<asac> i am saying that exactly the uImage we are now producing works on my SD card :)
<lool> asac: With which uboot?
<asac> and i can boot it
<asac> the same version
<ogra> hmm, still hangs with our image
<asac> could be its the previous code drop
<lool> Ok so our uboot + out uImage work?
<asac> from FSL
<asac> my uboot works with our uImage
<asac> out uboot doesnt work even with the F32 dropped
<lool> But our uboot doens't work with our uimage?
<asac> so i will check the Load Address now
<lool> Ok
<asac> yes
<asac> my uboot works with everything
<lool> Even the load address?
<asac> the Load Address is completely irrelevant
<ogra> but you dont use mkimage from the archive
<lool> Yeah it's overruled
<asac> you specify the load address on the fatload promt
<asac> prompt
<lool> Yeah
<asac> and thats what is used
<asac> right
<lool> The entry point might matter though
<asac> anyway. let me still try ;)
<lool> It's wrong too
<asac> doesnt matter for my other image
<asac> well. atr least that one works ;)
<asac> let me check
<asac> using 0x90008000 for both now
<ogra> lool, i'm testing with the same avlues FSL uses and it doesnt work
<asac> right.
<ogra> asac, so which mkimage do you have installed atm  ?
<asac> karmic
<ogra> the one from the archive or the one from source
<asac> karmic archive
<asac> maybe its oosync?
<ogra> shouldnt be
<asac> did you update the archive?
<ogra> no, i dont touch mkimage
<asac> yeah
<asac> but i dont think its mkimage
<ogra> i uploaded a fresh uboot bin today though
<asac> whatever i do it works with the other uboot thing i had
<ogra> but that should only just have built now
<asac> ok
<ogra> there were a bunch of new patches
<ogra> we migh want to try that binary
<asac> yeah
<asac> not sure what changed though ;)
<ogra> 0064-ENGR00119505-MX51-BBG-Change-DDR2-settings looks intresting
<ogra> 0065-ENGR00119526-MX25-Fix-mmc-read-write-failure-on-mmc too
<ogra> the others are rather generic or other mx platforms
<asac> ok so the fsl image really works
<asac> which is strange ;)
<ogra> yes
<ogra> and the worst is, there is no documentation to find anywhere how it was produced
<ogra> mkimage -l is all i can get
<ogra> which is how i found my load address and entry point defaults for initial testing
<asac> i really think its just the size difference
<ogra> i doubt that
<asac> at that stage uboot doesnt do much with it
<asac> just parse header and load to mem
<ogra> i managed to boot your uImage too last week, remember ?
<asac> the uImage we produce works fine on my other SD card
<ogra> with a fully manually created SD
<asac> yes. but my uboot from december works for everything
<asac> you cannot break it
<asac> ;)
<ogra> do you remember which config you used to build it ?
 * ogra guesses the oine thats gone from the tree in the last two uboot drops
<asac> i used mx51 ... it was the last code drop
<asac> (e.g. the first uboot 2009.08 we had)
<asac> ogra: no. it was the new config
<ogra> ah, yeah, the config was redone afterwards
<asac> just not the same code drop we are using now
<ogra> hmm
<asac> the one before
<asac> and i build it in karmic
<ogra> right, i use the same
<ogra> but from the package
<asac> those are the different parameters
<asac> karmic + old code drop
<ogra> built in lucid on a babbage
<ogra> smae code drop
<asac> ogra: the package is the december code drop, isnt it?
<ogra> but from the package
<ogra> was
<ogra> until today
<asac> yes. but i used the one before that
<ogra> the one i use is the same as yours
<asac> you went back?
<asac> to Nov?
<ogra> we had no .08 drop before that
<asac> odd
<asac> my image was produced on Dec 07
<asac> maybe the last karmic code drop already had that?
<ogra> the dec. drop i uploaded right before my holidays has the forst 2009.08
<asac> yes, but thats after 07 Dec
<ogra> and was the first code drop i ever published
<asac> so it means there was a 08 code drop before
<ogra> where did you get that ?
<asac> ogra: you uploaded the one from before somewhere
<asac> and i took that
<ogra> hmm
<asac> let me check if i still have it
 * ogra looks at chinstrap
<asac> deleted it :(
<ogra> well, its nothing we can use anyway
<ogra> and i think its more a prob of karmic vs lucid building
<lool> asac: Try using our kernel in FSL image?
<ogra> which remonds me, we likely dont have a dove lucid build either
<lool> mkimage it with FSL args and put it on a copy of the FSL image?
<ogra> ## Booting kernel from Legacy Image at 90800000 ...
<ogra>    Image Name:   LinuxRocks
<ogra>    Image Type:   ARM Linux Kernel Image (uncompressed)
<ogra>    Data Size:    3062156 Bytes =  2.9 MB
<ogra>    Load Address: 90008000
<ogra>    Entry Point:  90008000
<ogra>    Verifying Checksum ... Bad Data CRC
<ogra> ERROR: can't get kernel image!
<ogra> aha
<asac> let me build a .bin in karmic chroot
<lool> ogra, asac: I updated the script to drop explicit rms since cleanup() will take care of that; I think you guys need to figure out the contents now, the script itself seems ok except perhaps for the mkimage call
<lool> Can't help you much more without hardware I'm afraid
<ogra> yeah, thanks so much
<asac> thats ok ;)
 * ogra hugs lool 
<asac> thanks a lot
<lool> np
 * ogra has david call in 10 ...
<ogra> asac, so resetting the board with a configured uboot gets me the above with our uimage
<ogra> Bad Data CRC seems the prob here
<asac> yes. we need debug in fat and so on
<asac> i am sure that there must be issues during loading things
 * ogra tries the new uboot.bin
<asac> new?
<ogra> todays
<asac> ah
<asac> so on karmic we build with -marm
<asac> is that the case for lucid too?
<ogra> yes, its upstream in 2009.08
<asac> kk
<ogra> i dropped the patch today
<ogra> you said you didnt have to patch the inline functions for your build
<asac> no clue. it was the code drop we dont have anymore. i applied all the upstream patches and made a build without packaging
<asac> so yeah. most likely
<asac> upstream==fsl
<ogra> hmm, i wonder why gcc didnt choke on the inline functions
<ogra> are you sure you used gcc 4.4 ?
<ogra> 4.4 will definately not accept them
 * ogra needs coffee for the call 
<asac> ogra: yes. i did the same i remember now (looking at the patch)
<asac> or i used static inline
<ogra> ok
 * ogra is our for 1h
<asac> apw: so i think we didnt come to a conclusion on the kernel upload. will that just happen tomorrow?
<apw> asac, sorry?
<apw> should i not be uploading?
<asac> nono ... it _should_
<plars> what happened with the livecd builds over the weekend?
<armin76> asac broke them
<lool> plars: clementine needs a reboot
<lool> plars: IS is aware
<apw> asac, ok well it'll happen as soon as i can get the damn thing to build correctly ... its resisting
<asac> hmm
<asac> ok
<apw> asac, its on the buildd
<asac> apw: rock!!!
<apw> you get to keep both pieces :)
<asac> heh
<asac> ogra: did you enable ext2 in latest .bin already?
<ogra> asac, no, should i ?
<ogra> asac, in my testing it didnt change a thing, loading hung with etx2 was well as with vfat
<ogra> apw, "* drop a number of modules no longer built" what are these ? is there a list ?
<dmart> disconnect
<dmart> ...er...
<ameya> Hi everyone!
<ameya> Has anyone tried building lucid rootfs (ubuntu-minimal) with rootstock?
<rcn-ee> ameya, the lucid change hasn't landed in rootstock yet, however i'm using this for the moment: https://code.launchpad.net/~beagleboard-kernel/+junk/project-rootstock-lucid
<ameya> I am using the same
<ameya> I received "ubuntu-minimal: Depends: ureadahead but it is not going to be installed"
<ameya> and finally Kernel panic - not syncing: Attempted to kill init!
<ameya> I: Killed ...
<rcn-ee> weird...  my daily test build worked this morning: http://rcn-ee.homeip.net:81/dl/daily/ubuntu-lucid.log
<rcn-ee> actually my "xfce4 image" worked after the 'ubuntu-minimal' kernel panic'd...  I'd give it another try, lots of changes going on...
<ameya> I am using: project-rootstock/lucid-support : 33
<ameya> I checked at packages.ubuntu.com that ureadahead for lucid is only available for amd64 and i386
<ameya> if ubuntu-minimal depends on ureadahead then won't it create a problem?
<rcn-ee> packages.ubuntu.com doesn't list arm, it's here: http://ports.ubuntu.com/pool/main/u/ureadahead/
<ameya> ohhh! thanks :)
<ameya> can you tell me your command for building lucid?
<ameya> I will try again
<rcn-ee> ameya, i would just try it again, packages for lucid are updated daily, so something was weird at your time of running it.. Nothing special: sudo ./rootstock --fqdn beagleboard --login ubuntu --password temppwd --imagesize 2G --seed nano,linux-firmware,wireless-tools,usbutils --dist lucid
<ameya> hmm
<lool> ameya: ubuntu-minimal wont depend on ureadahead on an arch if it's not available
<lool> (germinate does check that)
<ameya> lool, Thanks!
<plars> trying alternate on dove and seeing a debootstrap error configuring required packages, anyone tried alternate recently and seen that?
<plars> NCommander maybe? ^
<plars> odd, seems to still be making progress in the background even though I didn't tell it to continue yet
<NCommander> plars, ugh ....
<NCommander> plars, can you check the imx51 alternate as well?
<plars> NCommander: not at the moment
#ubuntu-arm 2010-01-12
<ADcomp> hello .. I can't run X with omapfb :/  some help ?  http://paste.ubuntu.com/355265/
<rcn-ee> ADcomp, i think omapfb requires running a dss2 enabled kernel: "Error opening /sys/devices/platform/omapfb/ctrl/name: No such file or directory" Although i've never run it on anything else either...
<ADcomp> hi rcn-ee .. I finally running karmic on my new board  :)
<ADcomp> but I don't compile new kernel from your tree yet ..
<rcn-ee> hi ADcomp, i saw that.. (i was going to ask you about that too..)
<rcn-ee> (i'd like to get all omap3 based boards working in that tree)
<ADcomp> I don't have a working OE setup for compiling kernel ..
<rcn-ee> omapfb isn't really a driver per say, (doesn't interact with the SGX engine) it just enables some features... http://git.debian.org/?p=collab-maint/xf86-video-omapfb.git;a=tree;f=src;h=45b69d636f30e09cfdc817c95856297986dd8883;hb=HEAD
<ADcomp> btw touchscreen doesn't work ..
<rcn-ee> probably isn't enabled in the defconfig, the original beagleboard doesn't have one..  might even have to patch for it..
<ADcomp> I don't think so .. It works fine with angstrom with same kernel
<rcn-ee> there's a lot of kernels out there, (i just put two more out yesterday) which Angstrom works, and which one fails...
<ADcomp> I think it's related to HAL
<ADcomp> (EE) ADS7846 Touchscreen Unable to query/initialize Synaptics hardware.
<ADcomp> (EE) PreInit failed for input device "ADS7846 Touchscreen"
<rcn-ee> ADcomp, looking thru my tree's i've never enabled CONFIG_TOUCHSCREEN_ADS7846 which is what is needed..
<ADcomp> it's enabled in my config ..
<ADcomp> CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=y
<rcn-ee> sure, but that's why it doesn't work with my kernels or Angstrom's...
<rcn-ee> if you build my 2.6-stable, add this to yesterday's patch http://pastebin.com/f1fe738b3
<ADcomp> do you think I can use this to setup OE and compil kernel ?  http://wiki.openembedded.net/index.php/Getting_started
<rcn-ee> that's old, use http://www.angstrom-distribution.org/building-angstrom
<ADcomp> ok .. ty.  what about MACHINE ?  beagleboard ?
<rcn-ee> btw, that ADS7846 is a spi device, so arch/arm/mach-omap2/board-omap3"board".c will need to be patched.. spi devices need to be registerd...
<rcn-ee> note sure... it's a beagle, but at the same time it's different.. all machines are listed in tree/conf/machine.... doesn't look like there is a tao...
<ADcomp> no .. but I can maybe ask to technexion for thunder.conf they use to build angstrom ?
<rcn-ee> ask them for an Angstrom (OE) overlay, a lot of companies are doing that now days. (specially for omap3 boards)
<ADcomp> btw , this board is running fine under karmic .. X + Openbox   :)
<lool> Hmm trying to run rootstock, I get mount -t devpts devpts /dev/pts
<lool> mount: mount point /dev/pts does not exist
<ogra> lool, hmm, i thought there is a mkdir -p in the code
<lool> ogra: I dont see any
<lool> This is in the installer BTW
<lool> I tried moving udevd --daemon up one line, and get /bin/installer: line 14: udevd: command not found
<ogra> hmm, the mount should probably run after udevd starts
<lool> I suspect ubuntu-minimal isn't pulled
<ogra> yeah, smells like
<ogra> since you asked me to drop the hardcoding for it ;)
<lool> It says the default is ubuntu-minimal
<ogra> it should
<ogra> unless debootstrap has some out-of-sync'ness
<lool> debootstrap will use priorities to select packages
<lool> I'm trying with an explicit ubuntu-minimal now
<lool> same thing
<lool> udev was certainly downloaded
<lool> I think it's broken for vms; not sure why
<lool> second stage isn't set
<lool> The first failure is actually:
<lool> + echo chroot: cannot run command `debootstrap/debootstrap': No such file or directory
<lool> rcn-ee: Thanks for testing the --script patch; I tested it myself now and fixed a couple of issues with it
<lool> rcn-ee: Pushed a new branch and requested a new merge; http://paste.ubuntu.com/355487/ is the diff of the interesting changes, branch is lp:~lool/project-rootstock/user-script
<rcn-ee> thanks lool, just read the email actually..  ;)
<ogra> cooloney, they have to fix that
<ogra> they were in the crowd shouting for v7, neon and thumb2 too :) so they should make sure to have their code working with a recent compiler :P
<cooloney> ogra: yeah, understand
<ogra> asac, something for tonights call i guess
<asac> cooloney: ericm_: you asked if we have cross compilers availble
<ogra> ericm_, i thought lool prepared a ppa with cross tolls based on our compiler
<asac> i dont know ... can you explain to me where you get those from?
<asac> i thought you hvae to do them on your own
<cooloney> asac: yeah, cross compiler 4.4
<ogra> lool, ^^^ is that gcc 4.4 ?
<ogra> asac, you use codesourcery
<cooloney> asac: normally, we get the binary gcc from codesourcery
<ogra> but they are only on 4.3 iirc
<cooloney> asac: and i think the latest one is 4.3
<cooloney> asac: but i am searching on their site now
<asac> ah. i thought you have to do that on your own ... is there a good wiki explaining what you do?
<ogra> amitk's blog :)
<lool> I have cross compilers in my ppa
<lool> They are suitable for the kernel, but not for userspace due to a bug
<ogra> ericm_, cooloney, ^^^
<ogra> so use these
<ericm_> ogra, lool, thanks
<lool> We decided we wont go this way though, so I'm not investing in fixing these right now
<ericm_> lool, you have a link?
<lool> ppa:lool/ppa ?
<ericm_> lool, ok
<ogra> lool, as long as the kernel can be built ...
<cooloney> http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?@template=lite
<cooloney> i think we can try this 4.4 cross compiler from codesourcery now
<lool> For the kernel, you might have to remove the libgcc linkage which I think should be dropped upstream; I think it's a terribly old construct
<lool> Yes, codesourcery has 4.4 now
<amitk> I would be very conservative about updating to a new compiler
<amitk> they are almost always buggy
<cooloney> amitk: got you guys
 * ogra takes a break
<ericm_> I think I've already been using the latest codesourcery gcc
<ericm_> might be a good chance to give marvell toolchain a try
<persia> Native builds aren't that bad.  Try them!  You might find the results interesting, or even useful :)
<ericm_> persia, ok - will try
 * ericm_ needs some sleep
<cooloney> ericm-Zzz: good night
<asac> dmart: hi
<dmart> Hi
 * asac gets the thumb2 link
<asac> https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList
<asac> dmart: so can we clearly prioritize by what type of issue we have?
<asac> e.g. swp > ldr > mov > ldrex (or some other order)
<dmart> Maybe rather mov > (swp,ldrex) > ldr
<dmart> I need to talk to the kernel guys, but we have a patch to emulate SWP in the kernel.  This is slow, but it avoids us having broken packages and gives us a chance to migrate
<dmart> ldrex packages may not be SMP-safe
<dmart> ldr packages my just "perform a bit better" if built in ARM
<dmart> ...so I separated them out and we can consider them low priority
<asac> ok i added a few columns to the table
<asac> which we can later use to sort:
<asac> rdepends (number of packages that depend on it)
<asac> section (base, standard, optional)
<asac> and comments -> like for apex i added that its a none issue because its armv5 bootloader
<ogra> we do use sections ?
<asac> well
<asac> its good to identify if something is part of the base system etc.
<dmart> I found a few packages in main which have no rdepends in main... it might be worth tracking thta
<asac> like binutils: is probably more important than some app
<ogra> indeed
<asac> dmart: those packages usually automatically get demoted . we have a component-mismatches
<ogra> but i didnt know these sections actually mean anything in ubuntu
<asac> url
<asac> ogra: have that at hand?
<ogra> i thought they are debian only
<asac> ogra: they dont mean anything, but they give indication for the prioritization we are doing
<asac> :)
<asac> aka they still mean something, because they mean something in debian
<ogra> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<ogra> ^^^
<asac> dmart: thx
<asac> ooops
<asac> ogra: thx
<dmart> I don't mind :)
<asac> dmart: that page above is regularly reviewed. stuff that has no rdepends in main should get demoted
<dmart> OK, maybe we don't need to worry too much about that then
<asac> look for " Source and binary demotions to universe
<asac> "
<asac> right
<asac> dmart: you said in your mail you wanted to do something ... and before that we shouldnt remove anything from that list. did that happen?
<asac> i dont mind to keep everything in there
<dmart> If things get deleted, we don't track _why_ they were deleted... but we could move them to a separate table, with a brief note about why
<dmart> That was my only concern
<asac> ah ok. thats ok then. i think the comment column is good enough for now
<asac> right
<dmart> I think the first job is to do a fairly quick review through the whole list, getting the info for your suggested colums, and quickly assessing the impact of the source code issues
<dmart> Maybe it would be easiest just to chop the list for main into a few pieces and try that?  Do you know who would be available to review?
<asac> right. so the mechanic stuff i can get someone doing (e.g. fill in the number of rdpends and then sort the wiki page
<dmart> Yep, that should be fairly straightforward and quick to do
 * ogra is happy to report that the imx51 kernel in the archive works well 
<dmart> ogra: Is that 2.6.31.602.3?
<ogra> yep, the one uploaded yesterday
<dmart> Ah... I have a board here running it too
<dmart> seems OK
<asac> dmart: do you think it would take longer than 1h or so if we go through the list together here to add tne initial comments? that would ensure we make the progress and we dont have to wait on someone ;)
<ogra> its aweesome
<dmart> asac: No, that sounds like a good first step
<asac> then i will get someone filling the sorting columns and we can distribute the real porting tasks to individuals based on that
<ogra> way better than any first-release we ever had
<asac> ok lets get started then ;)
<asac> #startmeeting ;)
<ogra> haha
<asac> binutils
<dmart> ?
<asac> thats the first package in the table ;)
<dmart> apex is first (though probably ignorable)
<asac> let me open the filtered lists
<asac> dmart: yes, already filled in the comment ;)
 * dmart hits refresh
<dmart> ah
<dmart> Might it be better to split the list and work offline?
<asac> if that works for you. i just think its going to take longer that way ;)
<asac> unless one takes all the workload
<dmart> Maybe
<asac> let me open the filtered files ... then i hope it will go quicker
<dmart> All binutils and gcc packages: I suggest to ignore. This is dealt with separately with doko etc.
<asac> right
<asac> i can fill in the comments we find
<asac> so we dont get conflicts
<asac> dmart: eglibc too i guess?
<dmart> Actually, gcc-4.4 has a problem with swp in the boehm-gc code... I'll try and find the lp bug tracking this for openjdk
<dmart> Hmmm, no lp bug.  Can you add a note on that?
<asac> yes
<asac> added that to comments
<dmart> boost1.38 and boost1.40 both contain spinlocks and atomics code using swp
<asac> ok finally have all the filtered files
<asac> ok
<asac> noted
<asac> cacao-source ->
<dmart> How to I find out the rdepends for a source package?
<dmart> cacao-source has the same boehm-gc problem as in gcc-4.4, and also uses swp in a couple of other places.
<asac> ldrex seem to be used in armv6 header there
<asac> dmart: hmm. you have to check rdpeends for the binaries
<dmart> Oh, OK
<asac> one could write a script for that
<dmart> I was hoping you had one :)
<asac> or are you looking for build-rdepends?
<dmart> Not really, should we?
<asac> dmart: no. but i will get someone else fillin the rdepends ;)
<dmart> OK
<asac> dmart: that would be useful if we have issues in inline funcs in headers
<asac> but i hope not ;)
<dmart> Do you want to move this discussion to another channel?  This is a lot of spam for people who aren't interested
<asac> dmart: i think its ok this channel quite quiet ... if you prefer we can go somewhere else
<persia> apt-cache rdepends ${package} can be useful
<dmart> asac: OK, stay here for now them
<persia> But one has to check the results, as it also lists Conflicts and Breaks, etc.
<asac> dmart: unless someone complains ;)
<asac> so cln
<dmart> aptitude is also useful
<asac> grep cln * | pastebinit
<asac> http://pastebin.com/f33d714b6
<dmart> cacao-source:
<dmart> ... is a JIT and it likely to make a lot of assumptions about ARM versus Thumb-2... some real work is probably needed for this.  We should check with doko on priority for this one
<asac> dmart: yes. i will add a comment about jit needing work
<dmart> cln -> I already had a brief look.  This is some kind of arbitrary precision library. The seems to be some run-time compilation for ARM, but comments in debian/rules say it's broken and appear to disable it anyway.
<dmart> I think there are no rdepends in main for this one?
<asac> check apt-cache rdepends libcnl6
<asac> there should be a bunch
<asac> oh in main
<asac> yes the lib is in binary demotions
<asac> http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<asac> but probably "pi" is used
<asac> hmm. just by the lib from what i can tell
<dmart> You can check this with a limit like ~smain~Dlibcln in aptitude
<asac> dmart: so based on the grep those movs in cln needs to be fixed?
<dmart> pi is a demo program which computes pi :)
<dmart> In debian/rules it says "CLN's assembler support is not working properly ..." and adds -DNO_ASM.  I did an offline build--- it builds in Thumb-2 without errors and the testsuite passes OK, so I think the assembler is not used.
<asac> ok. great.
<asac> noted
<dmart> OK
<asac> coreutils
<asac> http://pastebin.com/f5115c6cb
<asac> seems just one swp
<asac> in a test
 * asac checks build log if make check is run
<dmart> I think that's a false positive... doesn't look like assembler to em
<asac> yes
<asac> that test passes
<asac> PASS: misc/printf-cov
<asac> on armel
<asac> http://launchpadlibrarian.net/33115198/buildlog_ubuntu-karmic-armel.coreutils_7.4-2ubuntu1_FULLYBUILT.txt.gz
<asac> but that was karmic
<asac> e.g. needs to get respun
<dmart> I can't see any reason why printf would have atomics anyway
<asac> ok db
<asac> i thinnk i fixed db4.2
<asac> at least i added gcc atomics there to fix a build failure
<asac> and the newer db versions seem to use pthread mutexes
<asac> like db4.6 doesnt use that code anymore iirc
<dmart> OK... db (4.8), db4.2 and db4.6 all seem to have the same code; can we apply the same patch to them all?
<asac> dmart: yes, we probably can, but only 4.2 failed on that code, which is why i didnt do that
<asac> anyway, we might want to do that anyway, and hope it flows upstream at some point
<asac> noted
<asac> djvulibre
<dmart> Might be a good idea.  Code involving swp will generally work (and pass tests) on our current platforms (except maybe on dove under stress?) ... this is more for avoiding future problems.
<asac> search-arm-mov.filt: ./djvulibre-3.5.22/libdjvu/GThreads.cpp:                    "mov%?\t%|pc, %1"     // branch to address %1
<asac> dmart: hmm ... strange that it failed to build for db4.2 though
<asac> anyway, lets continue
<asac> i noted that we should put the patch everywhere
<dmart> db* - should we flag this up for SMP safety, or are you confident the memory barriers implied by the GCC intrinsics are adequate?
<asac> lets flag this up. no clue if i messed it up ;)
<asac> noted
<dmart> OK, djvulibre
<asac> seems that mov is assembler ...
<dmart> Looks like it may need fixing. mov pc, <Rn> won't interwork correctly if built in Thumb.
<asac> right
<dmart> If it's in threading code, the branch could be supposed to go absolutely anywhere
<asac> yeah
<asac> ok ... dmake
<dmart> dmake - looks like a false match: it's a sed munge in a Makefile
<dmart> SH_n    = $(@:s/swp-/-/:s,-,/,:s/scripts/${SCRIPTFILE}/)
<asac> noted
<asac> i have eglibc currently in the same boat as gcc etc.
<asac> if you disagree we can make that a doko tasks
<asac> search-arm-mov.filt: ./emacs23-23.1+1/lisp/emulation/pc-select.el:     (pc-select-add-to-alist pc-select-saved-settings-alist ,var ,var)
<dmart> It might be a good idea to flag up all the toolchain type stuff for doko to give a judgement on
<asac> emacs23 sems to be a false positive
<asac> grep erlang * | pastebinit
<asac> http://pastebin.com/f7ec03435
<dmart> I guess so. I think elisp is strictly interpreted
<asac> (emacs: the .el line is the only line that is in your filtered list, so its a false positive, yes.)
<dmart> erlang: someone needs to take a more careful look.  There might be some runtime code gen in there
<dmart> It looks a bit like it from the matches
<asac> yes, and the grep shows code that needs to be checked
<asac> espeak
<asac> search-arm-mov.filt: ./espeak-1.41.01/platforms/riscos/s/assemb:MOVNEr8,pc
<asac> hmm. riscos?
<asac> would that be us?
 * asac wont think so
<ogra> ubuntu-risc FTW !
<asac> evolution-data-server
<dmart> Unlikely to apply to us.  Someone chould probably check it out... maybe some code was written for riscos but reused on ARM generally.  But it feels low priority
<dmart> (last comment applies to espeak btw)
<asac>  ./evolution-data-server-2.28.1/libdb/dbinc/mutex.h:asm volatile("swpb %0, %1, [%2]"
<asac> seems that might be atomics
<dmart> Looks like it
<asac> noted
<asac> ffmpeg -> guess that needs to build first ;)
<dmart> FTBFS, or just not built yet?
<asac> http://pastebin.com/f5558192
<asac> dmart: it currently ftbfs even
<asac> http://qa.ubuntuwire.com/ftbfs/
<asac> https://edge.launchpad.net/ubuntu/+source/ffmpeg/4:0.5+svn20090706-2ubuntu4/+build/1409808/+files/buildlog_ubuntu-lucid-armel.ffmpeg_4:0.5+svn20090706-2ubuntu4_FAILEDTOBUILD.txt.gz
<asac> but chromium ffmpeg builds ;)
<dmart> We should check whether chromium ffmpeg is using the ARM asm and NEON in particular
<dmart> ... should there be a separate ffmpeg there at all though?
<asac> we dont use NEON, because we dont have NEON atm and the rest of chromium will not use hwcaps to use it based on support
<Martyn> not surprised
<asac> dmart: well. we kind of accepted that trying to use system libs for chromium isnt worth the effort
<asac> they usually pull in snapshots
<asac> and bump the revisions pulled in frequently
<Martyn> I'm still trying to get NEON to work correctly in the latest builds of GCC
<dmart> I'll try and raise a lp bug on that.  Eventually, we do want good video performance in a browser ;)
<asac> Martyn: ffmpeg?
<Martyn> Even the latest CodeWarrior gcc doesn't seem to quite get it right
<asac> dmart: there is a bug related ... one sec
<lool> CodeWarrior or Sourcery?
<Martyn> CodeSourcery
<Martyn> Heh, spellcheck auto-fsked that
<lool> he
<asac> http://code.google.com/p/chromium/issues/detail?id=30991
<asac> dmart: ^^
<asac> thats where i asked about it
<asac> though it was for non ffmpeg related neon
<Martyn> however, I have seen some hand-coded ASM libs that reference NEON
<asac> guess ffmpeg could be done
<Martyn> and do the check to see if it's a vfp or NEON enabled processor
<dmart> For ffmpeg proper, we build a separate library flavour and use ld.so hwcaps
<Martyn> (not ffmpeg.  In muy case, it's marble .. a biotech program)
<dmart> There's a lot of hand-optimised code in ffmpeg anyway, so it may make sense to built ffmpeg with -marm.  This might be done already, but can you make a note to double-check it?
<lool> Not built with -marm ATM
<asac> dmart: i saved what we have for now. i will probably finish and fill in what i can see after call
<Martyn> lool : Shouldn't we be building with -marm?
<asac> ffmpeg? thats the plan afaik
<dmart> OK.  I guess ffmpeg needs a bit of further review, but it doesn't look like there's a major problem
<Martyn> Or is the effort to build v7-a thumb getting in the way of that?
<dmart> Martyn: in the way of what?
<asac> using -marm
<dmart> No, we can still use -marm for specific packages
<dmart> ...if needed
<dmart> [...]
<dmart> gccxml?
<dmart> Is this effectively a port of GCC? I was never too sure
<asac>  XML output extension to GCC
<asac> no clue ;)
<dmart> Another one for doko then.  I suspect it's a non-issue
<asac> http://paste.ubuntu.com/355573/
<dmart> hmm
<asac> ok noted
<dmart> gdb -> doko ?
<asac> yes
<asac> ghostscript seems to be false positive
<asac> grep ghostscript  * | pastebinit
<asac> http://pastebin.com/fc30016a
<dmart> agreed
<asac> search-arm-swp.filt: ./glib2.0-2.22.2/glib/gatomic.c:    "swp %0, %1, [%2]\n"
<asac> i think thats fixed
<asac> by using intrisincs if available
<asac> but i will add item to check that
<dmart>  I think I posted a patch for that :) I can probably get the bug number
<dmart> glib2.0: https://bugs.launchpad.net/ubuntu/+source/glib2.0/+bug/491872
<ubot4> Launchpad bug 491872 in glib2.0 "[armel] Atomic intrinsics are not implemented correctly" [High,Fix released]
<asac> yeah
<asac> ok ... taking quick break; then call!
<asac> saved the wiki
<dmart> OK, thanks for the progress so far, I think that's 30-40% of the main list
<asac> hehe yeah. took some time to ramp up, but that should be quick. of course loads of porting work will come out of this - so we definitly need to prioritize reasonably
<asac> hmm i busted the wiki table ;)
<dmart> Doing a quick first pass so we can make the right decisions seems the right thing to do
<asac> found the issue
<asac> yes
 * asac checks if ffox 3.6 is  happily spinning on arm before going away
<asac> ok seems like. waiting for xulrunner to finish: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3
<armin76> http://www.youtube.com/watch?v=_qGNj0YqFMM
#ubuntu-arm 2010-01-13
<debio264> would it be possible to run Ubuntu ARM on a EP93XX? They have ARMv920t processors with MaverickCrunch FPUs, although I wouldn't mind not being able to use the FPU.
<persia> debio264: Do you know which ARM instruction set those implement?  A quick web search isn't answering this for me.
<debio264> they run EABI, I know that much
<debio264> beyond there, it's ARMv9
<debio264> not sure what you mean
<persia> I think ARM9 is ARMv5, but I'm not 100% sure.
<persia> Basically, there are several revisions of the ARM core (e.g. ARM9, ARM11, etc.)
<persia> And there are several revisions of the instruction set (e.g. ARMv5, ARMv6, etc.)
<persia> I'm not 100% sure of the mapping, although I remember wikipedia having a decent entry about it.
<debio264> well, the Debian armel port apparently runs on these boards
<persia> But if it is ARMv5, then you would only be able to run Ubuntu 9.04, as 9.10 requires ARMv6 and 10.04 will require ARMv7.
<debio264> I'm reading up on that
<persia> Debian armel is ARMv4
<debio264> ah
<persia> It's very loosely parallel to the differences between 486, 586, 686, etc.  (but the specifics are completely different)
<debio264> are there any plans to change the armel minimum instruction set?
<persia> There have been plans to do that for each release, but always in the direction of only supporting newer instruction sets, so it's unlikely that ARMv5 will be supported in future versions.
<debio264> no, I mean on the Debian side
<debio264> (I've already been stung by the Ubuntu changes as my ARMv5 Sheevaplug used to run Jaunty)
<debio264> I guess I'm probably better off with Debian, actually, if the Ubuntu requirements are going to keep rising
<persia> I have heard some vague rumours that Debian may move to ARMv5 at some point, but nothing concrete, and I don't expect that would happen until there were vanishingly few devices still working that required ARMv4
<persia> But yeah, if you're using ARMv5 devices, Debian is probably going to be more satisfying.
<debio264> persia: okay, thanks for your help
<lool> JamieBennett: In your casper perf branch, I think you can replace the "chroot /root cat <some redirections>" with just "cat <redirections>"
<JamieBennett> Thanks for looking lool. The branch doesn't work at the moment as I got pulled of it for something else so there are probably other fundamental errors too but it gives an idea of the direction.
<ogra> wow
 * ogra just does the first SATA install on his babbage 
<persia> ?
<persia> Bit faster that way, is it?
<ogra> with a side-by-side resizing variant
<ogra> i dont expect it to be much faster since its still routed through USB, but that everything just works is impressing :)
<ogra> even though ...
<ogra> it seems to be faster ... 32% after 2 min is something i havent seen yet
<ogra> (32% of copying files)
<ogra> 41 now
<ogra> hmm,. its definately faster
<persia> USB isn't usually the bottleneck, it's that most people who install to "USB" are installing to flash, and the FTL tends to be slow.
<ogra> i never managed to get more than 20MB/s throughput
<cooloney> ogra: very happy to know that
<ogra> no matter if the attached disk was usb or sata
<persia> ogra: writing to what media?
<ogra> persia, doesnt matter
<ogra> rotary sata vs usb key
<ogra> both always had the same speed
<persia> hrm.  It ought to have mattered.  rotary SATA *should* be faster than flash for bulk write.
<ogra> that doesnt seem to be the case anymore
<lool> asac: You said in #506761 that you bumped the partition size; I guess the vfat one?  Looks like another bug in the uboot vfat code (was already broken with fat16 versus 32)
<ogra> 48% after 5 min install time is definately a new record though
<ogra> lool, he said that at 6am ... i bet he'S asleep ;)
<JamieBennett> :)
<ogra> wow, even the slideshow survived until 53% ... it is usually done at 15 :)
<lool> I think I nailed ffmpeg
<ogra> \o/
<ogra> god that install is fast ...
<ogra> 80% after 12min !
 * ogra wishes he had not chosen a german install ... downloading langpacks will slow everything down
<ogra> ok, that was 42min ... (vs 75min in karmic to a USB key) ... lets see if it boots now :)
<lool> Probably your USB key isn't as fast as a hard disk though
<lool> There is a difference between SATA on board and over USB in my experience, but not big
<lool> at least on b2.5
<ogra> well, but 30min ?
<ogra> i did SATA installs before in karmic (that couldnt start gdm)
<ogra> they were not that fast
<lool> It's kind of a pitty that I can't dchroot on the porter box
<ogra> why ?
<lool> It fails
<ogra> are you using the right runes ?
<lool> ogra: Try it out  :-)
<lool> I think cjwatson ran in the same issues when he looked into qt4-x11
<ogra> there was a trick i forgot about (since i never used the porter box)
<ogra> something like dchoot -l lucid ?
<ogra> or -c lucid ... dont know anymore
<lool> ogra: Try it!
<lool> It just aborts with a mutex assertion
<lool> I'm pretty sure we hadit in the past, but it would still login
<ogra> yeah, that was the issue you can work around with the option
<lool> I bet our kernel is too old
<dmart> Has anyone been getting slow networking with the new imx51 kernel?  I'm now getting only ~100kB/s and package updates take an age.
<dmart> I'm not sure if the kernel upgrade caused this, but my other boards are fine
<ogra> works fine here, i'm just installing chromium
<dmart> weird... maybe it's caused by something else
<ogra> though i switched to a usb wlan key after about 1h but didnt notice any slowness before
<dmart> I'll assume it's not a problem for now; I'll see if it keeps happening.
<ogra> i'm using a fresh install from the 12.2 image though ...
<ogra> might be userspace if you see it on an upgraded system
<dmart> Does that work?  I rsync'd it, but hadn't got as far as trying it yet...
<ogra> works awesome, i just installed to a SCSI disk in about 40min
<ogra> lots faster than the usb/karmic installs i tried
<dmart> The casper improvements?
<ogra> no, the SCISI driver :)
<ogra> *SCSI
<dmart> Oh... I don't have a board I can use that with yet :(
<ogra> it boots as slow as before, i dont think JamieBennett uploaded the new casper changes yet
<dmart> Oh, right.  Well I'll look forward to those
<ogra> though the install boots in about 30secs
<ogra> the disk throughput really changed
<dmart> When you say 30 secs, is that to gdm login, or to the desktop?
<dmart> I had 80 secs to the desktop on 20100108, booting from SD
<ogra> autologin to the desktop on third boot
<dmart> asac: Pulled firefox-3.6, and trying the benchmark now.  It seems to be working better than ff3.5
<ogra> hmm, hdparm disagrees with my personal feeling
<ogra>  Timing buffered disk reads:   54 MB in  3.05 seconds =  17.71 MB/sec
<ogra> thats not a high throughput
<JamieBennett> ogra: I'll be working on that next week but there is an initial branch for casper changes at https://code.edge.launchpad.net/~jamiebennett/casper/debconf-speedup-work
<JamieBennett> not quite working yet though
<ogra> yeah, i would have been surprised if it had made A2
<JamieBennett> The pieces are there they just need putting together when I get time :)
<ogra> yeah
<dmart> When ogra said "it's faster" I just jumped to conclusions ;)
<JamieBennett> :)
<ogra> chromium feels a lot smoother than FF ... i'm curious if the benchmarks will agree
<cooloney> ogra: if i wanna to try chromium on my board, need i add a PPA, right?
<ogra> cooloney, see other channel ...
<ogra> phew, scrolling in software center is unusably slow
 * ogra installs banshee for the fun of seeing it crashing
 * JamieBennett assign's ogra the "[jamiebennett] Banshee on ARM: TODO" task ;)
<ogra> haha
<ogra> no, thanks, i had that long enough during karmic :P
<JamieBennett> :D
<ogra> but who knows, probably it magically works now ...
<JamieBennett> ogra: bug 506910 - Is that in the installed system or on the live-cd?
<ubot4> JamieBennett: Bug 506910 on http://launchpad.net/bugs/506910 is private
<ogra> (if it ever finishes to install :P )
<ogra> hmm, audioCD and hardwareManager instances throw exceptions ...
<ogra> UI comes up but then it crashes ... as it was in karmic
 * JamieBennett changes that TODO to DONE now then ;)
<ogra> JamieBennett, both
<ogra> it persists after install
<ogra> oh, funny
<ogra> i had my headphone plugged to the mic input
<ogra> that actually generates mono output
<JamieBennett> ogra: OK, its to be removed from the seeds after the alpha's
<ogra> indeed
<ogra> though someone (upstream) should really look into pybootchartgui
<JamieBennett> Indeed
<ogra> its so broken on all arches
<ogra> dmart, ok, i switched back to wired, wget'ing http://cdimage.ubuntu.com/ports/daily-live/20100112.2/lucid-desktop-armel+imx51.img gets me "358K/s  ETA 30m 36s" seems to be fine
 * ogra will leave it running for a while to see if the value persists
<dmart> ok
<ogra> note that i'm running the latest kernel from the archive, not cooloney's new test kernel yet
<dmart> same here
<ogra> ok
<asac> dmart: thanks
<asac> ogra: did you try the new uimage script?
<asac> that works
<asac> or didnt you read all my bug comments ;)
<asac> i will close the bug now if you dont say it doesnt work
<dmart> Is anyone else seeing weird window corruption since the last xorg update?
<dmart> My first guess was that there was a pixman bug, but pixman hasn't been rebuilt since last November
<lool> dmart: Someone reported it here on beagle
<lool> dmart: Someone else mentionned this was a kernel vfp state corruption for which the patch was pending a merge upstream
<dmart> Do you know whether there's an lp bug?  I have some xwds I could attach.
<lool> freenode-#ubuntu-arm-20100104.log:11:05 < ssvb> cwillu_at_work: for pixman it means that the signal handler responsible for input handling may corrupt NEON registers and as these are used for processing pixel data, it results in image artefacts which look as horizontal stripes
<lool> 09:00 < ssvb> lool: but I know for sure that such problem existed with problematic kernels and it resulted in a similar looking artefacts on screen
<lool> dmart: 10:35 < ssvb> lool: here is a testcase for kernel bug: http://siarhei.siamashka.name/files/20100104/test-sighandler-vfp-corruption-bug.c
<dmart> I'm using babbage2 though... is CONFIG_NEON enabled in the kernel?  Pixman should not be using NEON.
<dmart> ...which leads to an interesting question: how do we handling enableing NEON on babbage3 but not on babbage2.x ?
<lool> dmart: that was supposed to be achieved as a kernel patch
<lool> But dont think anybody worked on that
<asac> dmart: do you have any first results from the benchmark yet?
<asac> like a rough direction?
<dmart> Rough answer is that ff3.6 works and is maybe 30% faster than ff3.5 on this benchmark.
<dmart> But chromium is up to ~90% faster than ff3.5
<asac> ok cool
<dmart> (The ff3.5 used in this comparison is ARM and karmic though, not T2 and lucid)
<asac> and mem consumption is sinmlarly better than 3.6?
<asac> yeah
<asac> anyway, looking forward to get the results :)
<dmart> Don't know about that; we don't measure it.  Is there a way to capture the peak memory use of a process?
<dmart> I'll send a mail with more detail.
<asac> hmm
<asac> good question
<asac> i would be more interseted in memory if you open like 100 tabs in both
<dmart> OK, I can try to do that.  What figure would you use?  The virtual memory load?
<asac> thats a good question ... folks usually look at RES mem
<asac> maybe not a real accurate figure, just understanding if either firefox or chromium make your system creep earlier would be helpful
<persia> creep or thrash?
<asac> depends on the load i guess ;)
<dmart> lool: do we know for sure that there is a signal handler using VFP/NEON, and do we know where it is?
<dmart> lool: Also, how do I see the IRC log? If I go to #ubuntu-arm-20100104.log:11:05 I just see an empty channel.
<asac> dmart: check if the log here is better: http://irclogs.ubuntu.com/2010/01/04/
 * asac lunch
<dmart> Better, thanks.
<ogra> asac, i havent tried your script yet, will doso now
<lool> dmart: Probably just my tz is one hour delta
<dmart> lool: It may make sense that switching to another pixman resolves the corruption problem: pixman-0.14.x (karmic) doesn't have the NEON support so cannot fall victim to the neon state corruption.
<lool> dmart: That's my personal log, as asac pointed out, we have irclogs.u.c
<dmart>  #ubuntu-arm-20100104.log:10:05
<lool> I use my logs for grepping
<dmart> ...no, I don't see anything there either
<lool> dmart: Yes, it turned out to be a kernel bug in that case
<lool> dmart: http://irclogs.ubuntu.com/2010/01/04/%23ubuntu-arm.html you don't see the conversation on pixman?
<dmart> Sorry... yes, on irclogs.ubuntu.com, I see it.
<lool> dmart: I certainly see the conversation at 10:05am in the log
<persia> The other isn't a real channel, just a local file
<dmart> Ah
<asac> the other?
<dmart> lool: The problem described is that the VFP/NEON regs are not saved and restored around signal handlers... but it still sounds unusual to use those features in a signal handler.  Do we know where it's happening?
<lool> #ubuntu-arm-20100104.log:10:05
<lool> That's my local log file
<asac> whats that?
<asac> yeah
<asac> but why does dmart have that ;)?
<asac> anyway. i am really out for lunch now
<lool> dmart: Well the patch would probably tell you; let me see
<dmart> He doesn't: hence the confusion :)
<dmart> Some random userspace app must have fp code in a signal handler? if so, the kernel patch won't explain where
<lool> dmart: http://www.spinics.net/lists/arm-kernel/msg67148.html
<lool> dmart: Oh dunno, I guess you could grep for signal() in pixman?
<lool> Or in xorg-server; I really have no idea which signal that is
<lool> It could be that some signal code gets built with cflags triggering the use of this code
<dmart> Hmmm, maybe it would be hard to find out.
<dmart> Maybe there are some apps which call pixman funcs from inside signal handlers.
<lool> dmart: This might be OMAP specific though
<lool> http://www.spinics.net/lists/arm-kernel/msg78429.html
<dmart> Yes, there's two issues: VFP/NEON save-restore around signal handlers, and save-restore around pm suspend. I don't think they're OMAP-specific.
<ogra> asac, did you test with dmart's uInitrd already ?
<ogra> dmart, do you have the mkimage command handy you used to create that uInitrd ?
<dmart> Sadly not... but it would have been something very similar to:
<asac> ogra: Ã³nly kernel
<dmart> mkimage -A arm -T initrd -C none -O linux -a 0x90800000 -d initrd.gz initrd.uImg
<asac> ogra: the mkimage is trivial
 * ogra wonders if there is dirt on his screen or asac started speaking french
<asac> dmart: sure it needs the -a?
<dmart> Kernel would be:
<asac> ogra: i have the same dirt ;)
<ogra> heh
<dmart> mkimage -A arm -T kernel -C none -O linux -a 0x90008000 -e 0x90008000 -d zImage uLinux
<ogra> ok, i'll try with these
<dmart> 0x90008000 was chosen to match what the linux/arch/arm/ makefiles to for babbage, but 0x90800000 was an arbitrary choice which seems to work.
<ogra> yeah
<asac> ogra: try the script first ;) .. then we can look at initrd
<ogra> argh
<asac> afaiu the -a isnt really needed :)
<ogra> why do we use initrd.lz everywhere
<asac> but if its help, we are set
<ogra> sigh
<asac> ogra: pick it from an install
<asac> there its a gzip
<ogra> i want the live initrd
<dmart> -a probably isn't needed for initrd; I couldn't remember
<asac> yes
<asac> just uImage
<asac> ogra: unpack it ;)
<asac> and pack it
<dmart> gzipped or non-gzipped initrd should work, but I only tried gzipped.  I never use U-Boot's own compression for this (but it probably works)
<ogra> dmart, we now use lzma ... not gzip anymore
 * ogra sighs about another special case we'll have to apply to armel image
<ogra> s
<asac> ogra: should be easy to repack
<ogra> asac, thats not the point
<asac> what is the point?
<ogra> we have to maintain every special case on treh build machine in separate code
<ogra> *the
<asac> you can repack in debian-cd ;)
<dmart> hmmm... well I think I just pulled an initrd.bin image from karmic.  Maybe is was lzma, maybe gz?
<asac> ogra: no. we can just repack when producing the mkimage ... in debian-cd
<ogra> asac, yes, thats the point, extra code that misses changes made for other arches
<asac> thats not really special casing
<asac> ogra: we run mkimage there
<asac> its one more command
<asac> thats not a deal
<asac> if all other archs would use uboot, i would agree
<persia> Um, is there a reason we can't use lzma?
<asac> but that code is special cased already
<ogra> still more extra code
<asac> persia: uboot doesnt support it
<persia> asac: And that can't be fixed easily?
<asac> ogra: i can write you that extra code ;)
<ogra> persia, i doubt anyone every added it to uboot
<asac> and maintain it ;)
<asac> persia: we can make that a lucid+1 project
<ogra> asac, its just that we try to keep the delts as small as possible
<ogra> *delta
<dmart> Linux will decompress the initrd: U-Boot doesn't need to understand it (surely?)
<lool> Yes
<asac> also uboot needs to be small
 * persia thinks it's even odds adding it to uboot or the build scripts, and prefers consistency with other architectures for documentation advantages.
<asac> ogra: you miss the point
<asac> the +armel is separate anyway
<asac> its no maintainence overhead to modify that
<lool> The code to uncompress/interpret the initrd is in the kernel for sure
<asac> anyway
<persia> dmart: Good point.
<asac> we have no choice ;)
<asac> so not worth discussing
<ogra> asac, no, it uses tons of existing non-arch specific scripts
<persia> asac: Except lool and dmart seem to imply that it doesn't matter how it's compressed.
<dmart> U-Boot has its own image compression code, but it's redundant because Linux is more flexible :)
<asac> if it doesnt matter i am fine
<ogra> and with these we just inherit changes made by the platform team
<persia> ogra: Let's do that then, and just use lzma.  We don't need uboot to decompress it.
<ogra> right, if it works i dont care, if we have to repack anything i'm unhappy
<persia> OK.  Does it work?
<lool> It might be slower to use lzma though
<dmart> Worth pointing out that you may need pass -C none to mkimage to make sure U-Boot doesn't do its own decompression pass
<persia> (someone with lucid-capable hardware should test)
<lool> Anyway, /me goes preparing for bunch of meetings
<asac> ogra: if we have to repack dont be unhappy. thats a one liner ;)
<asac> in a 100 lines arch specific file
<asac> anyway. i stop
<asac> ttyl
<ogra> asac, one we have to care for, out of sync with the rest of the distro
<persia> It's not worth arguing about.  One or the other of you should test passing "-C none" to mkimage to verify we don't need to care.
<ogra> asac, boots (and dies with an oops at the end)
<lool> asac: 10:34 < lool> asac: You said in #506761 that you bumped the partition size; I  guess the vfat one?  Looks like another bug in the uboot vfat code  (was already broken with fat16 versus 32)
<persia> ogra: kernel boots and oopses?  What's the oops?
<cooloney> hey guys, since versatile arch came back in lucid, can i use qemu to test versatile lucid image now?
<persia> Maybe we have the wrong kernel options?
<lool> cooloney: Sure
<lool> Not sure we enabled the d-i arch though
<lool> *subarch rather
<persia> cooloney: If there's a versatile kernel, you ought be able to use it, but you're in a better position than most to tell if the versatile kernel is correct :)
<cooloney> https://wiki.ubuntu.com/ARM/QemuNetInstall is quite out of date
<lool> cooloney: however you cant use it to test *images*
<dmart> lool, asac, persia: I didn't play much with fat myself. It would be handy if someone added ext4 support to uboot, but I don't think there's any plan to do it yet.
<lool> The images are meant to boot on this or that hardware
<cooloney> persia: frankly, i do not know where is versatile kernel
<lool> in practice, the images might be usable with special incantations though
<lool> cooloney: In the versatile .deb
<ogra> Kernel command line: noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw rootfstype=jffs2 ip=off
<cooloney> lool: ok, got your
 * ogra wonders where that comes from
<ogra> its not in printenv
<persia> That explains the oops, at least.
<cooloney> ogra: that command line should be in the UBOOT code
<cooloney> lool: do you know the URL of the versatile .deb?
<lool> cooloney: https://launchpad.net/ubuntu/lucid/armel/linux-image-2.6.32-10-versatile/2.6.32-10.14
<lool> Ah I was searching in main
<cooloney> lool: thx, a lot.
<lool> I cant find it on ports, weird
<cooloney> lool: no problem, thx
<lool> http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux/linux-image-2.6.32-10-versatile_2.6.32-10.14_armel.deb
<lool> Stupid proxy
<ogra> hmm, kernel doesnt find the ramdisk
<persia> Does the kernel have lzma support?
<ogra> its the one from the live image
<ogra> so yes
<ogra> RAMDISK: Couldn't find valid RAM disk image starting at 0.
<ogra> GRR
<dmart> What's your bootm command?
<ogra> bootm 0x90007fc0 0x907fffc0
<ogra> i just copied yours from the bug for now
<dmart> Did you supply -a to mkimage for the initrd image?  I'm wondering whether U-Boot is using the load address parameter to tell linux where the initrd is.
<ogra> i did
<ogra> mkimage -A arm -T initrd -C none -O linux -a 0x90800000 -d ../initrd.lz ../uInitrd.lz
<ogra> i'll try with -a 0x0
<dmart> Hmmm, not that then.  Can you send me your kernel log?
<asac> lool: yes. its a vfat issue. i will check the code if i find time
<asac> ogra: -T ramdisk
<asac> cooloney: why is our vmlinuz so big?
<ogra> RAMDISK: Couldn't find valid RAM disk image starting at 0.
<ogra> sniff
<asac> did you pass initrd=0x.....,12M to kernel?
<ogra> nope
<ogra> i shouldnt need to
<dmart> No, U-boot puts that info in the tagged list
<dmart> Can you stick your kernel log in pastebin, ogra?  I have vague memories of similar problems
<asac> its just that that is used everywhere on in u-boot docs
<asac> which i found odd too i have to admin
<ogra> dmart, you mean the serial output ?
<asac> admit
<dmart> ogra: if possible
 * asac gets more coffee
<ogra> http://paste.ubuntu.com/356054/
<dmart> ogra: thanks
<dmart> ogra:
<ogra> yep
<dmart> Trying to unpack rootfs image as initramfs... rootfs image is not initramfs (junk in compressed archive); looks like an initrd
<dmart> I guess that's wrong?  lzma support missing (or something else?)
<ogra> thats weird
<ogra> oh, wait !
 * ogra checks asacs script again
<asac> my script?
<asac> the kernel boots ;)
<ogra> my options to it
<ogra> no, its definately the right kernel
<asac> ok
 * asac remembers that this was the stage where his bbg3 died ;)
<ogra> hmm, -C lzma is accepted, but doesnt fix it
<asac> i think it should be -C none
<dmart> i AGREE
<asac> anyway
<dmart> (I agree)
<ogra> thats what i used before
<ogra> asac, do we have a call now ?
<ogra> or is that an IRC meeting
<asac> ogra: i will ping you ... have to call him first to tell him that we do a conference now ;)
 * ogra needs to know if he needs to steal the phone :)
<asac> as he isnt online atm
<asac> so stay tuned
<ogra> ok
<lool> ogra: Could you merge the two rootstock branches I proposed for merging?
<lool> They fix lucid support or running under lucid with default args, and would allow for less forks of the script
<ogra> lool, will do before ending my day, whgy dont you have direct commit access ?
<lool> I might, let me check
<lool> ogra: Trunk is ~ogra/project-rootstock/trunk
<ogra> ah, crap, i'll found a team
<cooloney> asac: sorry, just back from a meeting,
<cooloney> asac: are you asking about the size of vmlinuz?
<asac> cooloney: yes
<cooloney> asac: you guys are thinking the vmlinuz is too big? compare to karmic imx51 kernl?
<plars> asac: has https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9.1/+bug/490792 already been fixed? Isn't that the same fix I tested a while back?
<ubot4> Launchpad bug 490792 in xulrunner "ARM/Thumb interworking support missing from nanojit" [Unknown,Fix released]
<dmart> plars: firefox-3.5 is still SIGILL'ing in lucid, for reasons we don't fully understand yet... so maybe the problem wasn't fully fixed
<dmart> Has anyone been able to install from 20100112.2 with manual partitioning?  I'm having problems: see https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/506971 and https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/507012
<ubot4> Launchpad bug 506971 in ubiquity "Partitions detection is wrong using manual partitioning" [Undecided,New]
<dmart> (Come on ubot4, second link... https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/507012)
<ubot4> Launchpad bug 507012 in ubiquity "Attempt to create new partitions silently fails in manual partitioning" [Undecided,New]
<plars> dmart: according to iso tracker, ogra was able to get through it
<dmart> I'm trying to reserve space to transfer the boot images to the installation medium.  This is more convenient to use, and has worked in the past...  but maybe it's confusing ubiquity
<plars> dmart: I'm using automatic partitioning on this test right now, will try with manual later
<dmart> FYI, I create a 32MiB non-FS data partition (DA) at the start of the installation medium to put the boot images in.  This can't be done through ubiquity, but the partition is displayed correctly after ubiquity has queried the device.
<persia> dmart, just as a side note, ubot4 can also understand shorthand, such as Bug #507012 and bug #506971
<ubot4> Launchpad bug 507012 in ubiquity "Attempt to create new partitions silently fails in manual partitioning" [Undecided,New] https://launchpad.net/bugs/507012
<ubot4> Launchpad bug 506971 in ubiquity "Partitions detection is wrong using manual partitioning" [Undecided,New] https://launchpad.net/bugs/506971
<dmart> persia: useful tip, thanks
<plars> also, seeing an error with /usr/lib/cups/backend/scsi as soon as it comes up, but apport can't seem to locate the package (generated file maybe?)
<dmart> I also think that CONFIG_NEON=y is causing me problems on babbage2 (we have no babbage3 at present)
<dmart> I get unexplained full-system lockups
<plars> dmart: lockups when doing what?
<asac> cooloney: sorry. the problem is that uboot take a few second to load the vmllinuz from SD
<dmart> There's no pattern that I can see.  Usually, when I'm running nothing in particular (ubiquity just now) or when the board is unattended for a while.
<asac> cooloney: the fsl bin kernel is like 30% smaller ...
<NCommander> dmart, is there instability in general?
<asac> cooloney: so everything we can safe there would be great.
<NCommander> dmart, I remember reading somewhere that there were known issues with NEON on Babbage 1, and possibly also on the babbage 2
<asac> plars: thats fixed in firefox-3.6
<dmart> It feels like just a low-frequency random problem, but I didn't see anything similar with karmic.  This is the only kind of instability I see (apart for some app crashes of the sort which other people see too and which is to be expected for an alpha)
<asac> plars: there are two issues with firefox. the one we fixed, and that one from above.
<asac> the one above is only fixed in firefox 3.6
<asac> plars: firefox-3.6/xulrunner 1.9.2 are now available here: https://edge.launchpad.net/~ubuntu-mozilla-security/+archive/nss3.12.3/+packages
<plars> asac: ok, figured it might be something like that, thanks
<asac> will soon be in archive
<dmart> NCommander: you are right: babbage 3 is fixed, but all earlier versions have this problem.  We must address this config difference it in the kernel somehow since there are expected to be some products based on the babbage-2 SoC
<dmart> Note: I don't know if the lockups are connected with CONFIG_NEON, that's just my current guess.
<NCommander> dmart, but won't apps that have NEON just fault the board then?
<dmart> Unfortunately, it's not that simple.  Only certain memory accesses cause problems, and even then I think it depends on other factors.  I remember running a NEON-enabled ffmpeg on babbage-1: some runs it would work OK; on other identical runs the board might freeze
<NCommander> dmart, uuuuuuuuuuuuuuuuugggggggggggghhhhhhhhhhh :-/
<dmart> This is why CONFIG_NEON was =n
<NCommander> dmart, but disabling CONFIG_NEON doesn't prevent NEON instructions from actually being executed, does it?
<dmart> ...but for babbage-3 we really do want it =y
<NCommander> dmart, there are a couple of ways we could handle it if need be.
<dmart> NCommander: CONFIG_NEON=n will turn some NEON instructions into SIGILLs, but unfortunately not all of them because there is some overlap between the VFP and NEON opcode spaces.
<asac> NCommander: chromium neon code definitly triggers SIGILL ... i was told because of CONFIG_NEON=n
<dmart> Could be... I've probably only run it with CONFIG_NEON=y.  It works well (apart from the slight board instability)
<NCommander> dmart, so even flipping CONFIG_NEON won't solve the issue
<dmart> If Chromium is dependent on NEON and cannot adapt at run-time, it's a bug: not all target platforms have NEON anyway.
<asac> i pointed you to the bug ;)
<asac> they dont see that worth the effort
<asac> but i guess they would be open for well maintainable patches
<dmart> Can you point me to the bug again?  I seem to have lost it.
<asac> dmart: maybe coming up with a good list of devices that will have this well help
<asac> one moment
<asac> http://code.google.com/p/chromium/issues/detail?id=30991
<asac> dmart: ^
<asac> check comment 4
<asac> cooloney: so we have CONFIG_NEON=y now?
<cooloney> asac: yeah, it is turned on
<asac> dmart: so should we or shouldnt we have that on? or do we first want to confirm that bbg2 breakage is really due to that?
<dmart> I'll discuss with cooloney a bit first
<ogra> plars, dmart, i didnt do manual partitioning, but a rezize+side-by-side install to keep my build chroot on the dosk (we dont have an option for that on the isotracker, manual just seems closest)
<ogra> *disk
<plars> ok
<plars> ogra: did you see this cups backend bug also?
<plars> seems to be a stack smashing thing
<ogra> nope
<plars> ogra: odd, comes up every boot for me
<ogra> i only saw a pybootchartgui apport msg and a "scsi died" apport one
<ogra> i wasnt able to reproduce the latter to get apport data though
<plars> ogra: right, it's the scsi one
<plars> doing it now
<ogra> thanks
<ogra> i only saw it once
<ogra> and it didnt return
<ogra> GrueMaster, plars, (or whoever tests the current imx images) can you make sure the logout menu is populated ?
<plars> ouch... /me considers going out for lunch while lp logs in
<ogra> that was one we did the respin for
<ogra> plars, dont try to use FF with LP from the babbage ... something is wonky there
<plars> grr, ff just died
<plars> yeah, I see now
<GrueMaster> Sure, but it may be a little while.  I just triggered my image pull, and I have a dental appointment in 1 hour.
 * ogra immediately switched to chromium :)
<plars> ogra: it is not populated, but I'm on 20100112.2, not on 13
<ogra> right, 12.2 had that
<ogra> 13 is supposed to fix it
<plars> also, the power control menu appears to be separated from the indicator applet session now
<ogra> we had a bunch of outdated packages on 12.2
<plars> ogra: iso tracker still points to 12.2 as the one to test
<ogra> i just got a mail notification for 13, weird
<plars> oh
<plars> no, it updated now
<plars> crap
 * plars starts over
<plars> it was at 12.2 when I started this morning :)
<ogra> yeah, 13 just finished
<ogra> got the mail 20min ago it seems
 * ogra was busy with uboot, so didnt notice it until now
<ogra> device-mapper: dm-raid45: initialized v0.2594b
<ogra> Done.
<ogra> Begin: Running /scripts/init-premount ...
<ogra> Done.
<ogra> Begin: Mounting root file system... ...
<ogra> Begin: Running /scripts/casper-premount ...
<ogra> Done.
<ogra> Done.
 * ogra dances madly 
<ogra> asac, ^^^
<ogra> :D
<plars> aha!
<plars> nice :)
<asac> ogra: rock and roll. please update us
<ogra> mmcinfo; setenv bootargs 'console=ttymxc0,115200 boot=casper'; fatload mmc 0:2 0x90300000 uImage; fatload mmc 0:2 0x91600000 /uinitrd; bootm 0x90300000 0x91600000
<ogra> thats my magic
<asac> how much space do you give kernel?
<ogra> uinitrd created with: mkimage -A arm -T ramdisk -C none -O linux -d ../initrd.lz ../uInitrd
<asac> 0x1300000
<ogra> yep
<asac> 19922944
<ogra> enough i suppose :)
<asac> 19M?
<asac> thats too much
<asac> or does it need more space than the image?
<ogra> well, i wanted to play safe for getting it up and running
<ogra> not really
<asac> ok. i would hope we can use 5M
<ogra> why ?
<ogra> we have plenty of RAM
<asac> well. why waste
<dmart> I think Linux will sort out the memory layout during boot; the "hole" isn't wasted
<ogra> right
<dmart> (I think)
<ogra> i think youre right
<dmart> Anyway, the initrd should be freed after boot anyway?
<ogra> right
<asac> 2.5% is 13M
<asac> for 512
<asac> ok
<ogra> asac, it gets moved around after boot
<asac> so if its not wasted its fine
<ogra> but we can go with 10M if you feel better then
<asac> and those numbers are just random?
<ogra> i doubt we'll get a 19M kernel
<ogra> yes, its just where uboot loads it
<ogra> once it gets executed it gets moved
<asac> then why doesnt 0x9000800 work?
<asac> whats causing the breakage with that?
<ogra> uboot itself copies itself into ram
<ogra> 0x800 might be to small so the kernel might overwrite it
<ogra> (just guessing here)
<asac> 8000
<asac> but yeah
<ogra> 8000 should actually work, the important part is that initramfs doesnt overwrite parts of the kernel
<ogra> i'll try with smaller values ... at least i know it works now
<dmart> There may be a hard-coded assumption that the kernel image is loaded to 0x90008000, but I don't know for certain
<ogra> i think thats what bootm has by default
<dmart> For the initrd it shouldn't matter, providing it doesn't overlap anything else.
<ogra> right
 * ogra tries if the second option to bootm is actually needed
<dmart> Probably the kernel image must still not overwrite the initramfs after decompression (I think the decompress code is pretty much the first thing to run)
<ogra> i think it should work with only one
<ogra> meh, its needed
<dmart> That was the conclusion I came to... U-Boot doesn't seem to magically know it after you load in initrd uimage
<ogra> well, it does on the sheevaplug and beagleboard
<ogra> so i thought it does here too
<dmart> Hmmm...  maybe there's some magic if you pre-set something in the environment?  A lot of platform-specific things seem to be done this way.
<ogra> 0x90800000 and 0x91600000 works fine as well btw
<ogra> yeah
<dmart> cool
<asac> ogra: so shall i add a feature to the -script that just copies the initrd to / ?
 * asac just does that
<ogra> i'll touch the defaults of our uboot package soon
<ogra> asac, yep
<asac> ogra: so format doesnt matter ... just copy and use -C none?
<ogra> NCommander, so how do i teach our imx uboot to like .scr files ? :)
<asac> and -a and -e doesnt matter either?
<ogra> mkimage -A arm -T ramdisk -C none -O linux -d ../initrd.lz ../uInitrd
<dmart> .scr?
<ogra> thats what i used
<ogra> dmart, uboot script file
<ogra> you can hand the environment to it from a .scr file
<NCommander> ogra, the easiest way to test things is to take the dove bootcmd, and tailor it to the imx51
<asac> ogra: ok, so we will ship our uimages in / or /boot ... i assume we want the same defaults on live and on install
<ogra> makes changing the cmdline easier
<dmart> mkimage ... -C script ... ?  It works, but I had to put all the commands one one line, separated with ;
<ogra> yeah
<ogra> dmart, with the uboot from our package ?
<NCommander> dmart, you shouldn't hjave to do that with a script file.
<ogra> asac, for the live images the default is usually /casper
<dmart> ogra: possibly not the same one, but still derived from a recent fsl release
<ogra> asac, but we can change it to /
<asac> ogra: right. i think for now we should at least put the boot.scr at a fixed location. we can use different ones if we really want for live vs. install
<asac> or dont go for .scr in the first iteration at all
<dmart> NCommander: how else would I change the cmdline?
<ogra> asac, i guess we want a /boot formatted in vfat
<asac> yes
<ogra> asac, so we can load from /
<asac> so that would be / then
<asac> right
<NCommander> dmart, on dove? For live media, or an installed system?
<asac> so we dont need a .scr for first iteration
<ogra> nor for second
<asac> ogra: whats the second iteration?
<ogra> .scr is only intresting to make it easier to change the cmdline imho
<dmart> NCommander: Ah. I'm thinking of post-install on imx51.
<ogra> asac, no idea, you said first :P
 * ogra grins
<asac> ogra: ok. i just thought you wanted it ... if you dont want i am fine - at least until we have usb support in uboot for fsl
<NCommander> ogra, there are other benefits
<asac> someting like on dove doesnt make sense
<ogra> right
<asac> NCommander: usb doesnt work yet
<NCommander> there will soon be other benefits :-)
<asac> NCommander: where is the uboot source for dove
<ogra> NCommander, first target is to make uboot work like redboot ...
<asac> NCommander: thats not in the archive?
<ogra> on top of that we can do other shiny things
<ogra> NCommander, oh, right, you wanted to package that long ago :)
<NCommander> ogra, asac http://people.canonical.com/~mcasadevall/dove/Dove_UBoot_4_3_1_Full_Release_NQ.zip
<asac> NCommander: if it isnt, can you make that availbable in a prominent location ?
<ogra> NCommander, package it :)
<asac> NCommander: ok. that needs to go in the archive
<NCommander> asac, ogra, we never were able to resolve the redistribution rights on doimage's binary
<asac> oh
<NCommander> asac, it got caught up in Marvell's legal department
<asac> can you send me a mail with details?
<asac> thanks
<ogra> NCommander, cant you just make a .bin ?
<NCommander> ogra, ?
<ogra> from upstream plus patches ?
<NCommander> ogra, can't.
<NCommander> ogra, well, ok, I could
<ogra> oh, why ?
<NCommander> But it would be fairly useless
<ogra> right
<NCommander> Basically, we have the uboot source which compiles to a bin
<NCommander> but the board won't accept a .bin by itself
<asac> NCommander: please send me a short mail about the background and the current state. i want to keep this moving ...
<ogra> yes, i know
<ogra> but if you have doimage you can turn the .bin into something
<asac> just a real short one with the main bullets
<ogra> so having the .bin in the archive would help people owning doimage
<ogra> it takes less than 1h to copy the debian dir out of the uboot-imx package and make the needed changes i bet
<ogra> to turn it into a uboot-dove package
<asac> yes, thats what we should be doing as a first step
<ogra> right
<ogra> so people owning doimage could quickly recompile it with extra options they want
<asac> i have it on my radar now :)
<ogra> good
<ogra> asac, pushed a README to uboot-image-script with the working set of bootcmds
<asac> cool
<ogra> hmm, slight problem
<ogra> seems the NIC doesnt come up
<ogra> wow, thats bad
<ogra> ok, something to find out about tomorrow
<ogra> SHRIEK !
 * ogra sees setenv ethaddr 00:04:9F:00:EA:D7 in the freescale docs
<ogra> i hope we dont have to invent random HW adresses during uboot bootup
<asac> ogra: the nic doesnt come up at uboot stage?
<ogra> no, not at all
<ogra> i mean also not on the running system
<ogra> i cant even bring it up with ifconfig
<ogra> it doesnt get initialized
<asac> end the setenv helps?
<ogra> no idea, just trying
<asac> and
<asac> would be odd
<asac> driver loaded?
<asac> ;)
<ogra> no, that would be normal
<ogra> we had similar issues in redboot at some point
<asac> redboot wiping the mac in hardware?
<ogra> no, the nic not getting initialized
<ogra> if the silicon isnt powered up properly, the kernel cant fix it
 * ogra waits for the board to boot
<asac> but how can the boot loader power up something the kernel cant?
<asac> ;)
<ogra> it talks to the HW on a different level
<asac> you mean in a different mode?
<ogra> on a lower level
<ogra> call it mode if you like :)
<plars> ogra: the power control menu is populated on the live image, but not once it's installed
<ogra> well, setenv didnt help
<ogra> plars, sounds liek a bug
<asac> ogra: you use ramdisk for the type of initrd?
<asac> e.g. mkimage ... -T ramdisk ?
<asac> or initrd?
<ogra> asac, yes, what else should i use ?
<plars> ogra: was there a bug open for this already?
<ogra> asac, initrd isnt a valid keyword
<asac> right
<asac> i just saw you mentioned that
<ogra> plars, not from me, but slangasek told me about it, he might know
<asac> ogra: i will use uInitrd as name is that ok with you?
<ogra> sure
<ogra> whatever works :)
<ogra> hmm, so i guess i'll dive into the uboot code tomorrow to find out if the right NIC driver is used
<ogra> thats really weird
<ogra> cooloney, do you use the FEC driver from freescale or amitk's hacked up version from karmic ?
<cooloney> ogra: it is from fsl not amitk's version
<ogra> hmm
<ogra> ok
<cooloney> ogra: any problem?
<ogra> well, i noticed that i dont see plug events
<ogra> i was hoping the new FSL version fixes that
<ogra> (we didnt see them in karmic either)
<ogra> so network-manager doesnt react if i plug/unplug the cable
<amitk> cooloney: fsl probably didn't add the platform device patch that we have in karmic
<amitk> jeremy did that patch
<ogra> amitk, well, that didnt add plug events, just made it appear in NM ...
<amitk> right
<ogra> i see it in NM but still have to switch it on/off manually if i unplug the wire
<amitk> then they haven't implemented runtime PM
<ogra> seems they expose a platform device at least this round
<cooloney> ogra: cool, if we find a bug, please file a bug, and we can work on that
<ogra> will do
<ogra> hmm, i dont get why uboot doesnt have something like an fecinit command to bring the NIC up
 * ogra goes afk for now ... 
<asac> yes. i can boot into my lost karmic partition again ;) using lucid kernel/initrd
<asac> under lucid my usb storage disc is broken ... so really seems to be userspace breakage
<armin76> thats what happens when you rice!
<asac> probably ;)
<ogra> asac, did you check the NIC ?
<ogra> its probably a board specific issue that doesnt show up on all boards
<Riotta> hi
<Riotta> is here some Canonical developers responsible for porting ubuntu to arm architecture?
<Riotta> I heard about support from Marvell and Freescale with the ARM port and I would like to know how Open this support is do they provide source code or docs or binary blob & nda?
<Riotta> which company is more Open Source friendly
<Riotta> in other words
<asac> Riotta: which binary blobs?
<asac> Riotta: the images we produce (that work) have no binary blobs in there atm. of course not all hardware is fully supported
<Riotta> dunno if such exist it was a question
<asac> the current images we have, are all free
<asac> for both
<Riotta> ah i see
<asac> both companies are open-source friendly imo
<asac> of course both have legacy issues with suppliers etc.
<asac> old story etc.
<Riotta> okay
<Riotta> good to hear that
#ubuntu-arm 2010-01-14
<ogra> asac, i milestoned bug #457878 (since it still exists with the recent BSP drop)
<ubot4> Launchpad bug 457878 in linux-fsl-imx51 "imx51 on board ethernet plug/unplug events not detected" [Medium,Confirmed] https://launchpad.net/bugs/457878
<ogra> cooloney, ^^^
<cooloney> ogra: cool, will take a look when I am back to Shanghai, heh
<asac> ogra: you are sure your modules are loaded?
<asac> aka are you sure your kernel/initramfs you used for your uboot is identical with the one you have no your filesystem
<asac> i had the same behaviour yesterday, but it was all a version mismatch
<cooloney> dmart: thx for the email, could you please file a NEON bug in launchpad and assign it to me?
<cooloney> dmart: then we can tracker the discussion
<asac> ogra: asked for dmesg/syslog in bug
<ogra> asac, ??
<asac>  ogra in your ethernet bug
<ogra> are you referring to the bug above ?
<asac> or rather the bug you hi jacked
<asac> yes
<ogra> sure the modules are loaded
<ogra> its not related to uboot
<asac> yesterday you said there is no interface
<asac> now its just LOWER_UP?
<ogra> thats on a redboot booted system and is a long standing missing feature in the FEC driver
<asac> yeah
<asac> ok
<ogra> it was missing in all kernel versions we ever had
<asac> so that "no net at all" feature is fixed for you?
<ogra> no
<asac> where is that bug?
<ogra> thats what i'm looking at atm, i just wanted to make sure the above bug isnt forgotten
<asac> heh ok.
<ogra> i havent filed it yet, just looking at uboot code to make sure we build the right driver
<asac> do you see your interface at all?
<asac> i saw it
<asac> though i only have a read-only fs
<ogra> yes, you can see it, but you cant bring it up
<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
<asac> wireless is working flawlessly here :)
<ogra> and ifconfig says it cant assign an address
<asac> so i think its not a blocker to stop the uboot move in debian-cd
<ogra> (where it refers to the MAC)
<asac> yeah
<ogra> the only interface the bnoard has doesnt work ..
<ogra> i would consider that as a blocker :)
<asac> a release blocker yes,
<asac> but not a roll out blocker
<ogra> well, at least highest prio
<asac> sure, but we should do the uboot move before that
<ogra> well, uboot needs an upload anyway
<ogra> for the changed defaults
<ogra> we also need to consider that an installed system might not have /boot on the second partition
<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)
<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
<asac> its not a real solution
<asac> but we need to work on scripts to work on that
<asac> how are you doing that on redboot?
<ogra> we cant assume that once we install uboot to mtd flash
<ogra> redboot never goes into flash
<asac> once we install it there
<ogra> as soon as you boot from flash the first partition will be gone
<asac> at that point we must be able to interate
<ogra> thats what davidm wants as final install setup
<asac> sure
<asac> but we are not there yet ;)
<ogra> so users just flip a DIP switch in the end
<ogra> no, but i'd like to know in advance if it works :)
<asac> right. thats understood. just doesnt need to happen on the first iteration
<asac> it has to be made working.
<ogra> it works already :)
<asac> so you have an iterating boot.scr?
<ogra> but i dont feel good with all the hardcoding
<ogra> no
<ogra> it works as is
<asac> right. so dont bother about that
<ogra> with the hardcoded part2 loading
<asac> what i meant with has to be made working is that we can do that
<asac> yes.
<asac> 11:59 < asac> right. thats understood. just doesnt need to happen on the first iteration
<asac> 11:59 < asac> it has to be made working.
<asac> -> thats iterating boot.scr
<asac> ok
<asac> i am getting cigarettes and coffee
<asac> and then will stop bothering you ;
<asac> )
<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
<ogra> currently the only thing i want the scr for is the kernel cmdline
<asac> only boot.scr can test for something afaik
<asac> so you cannot test if something succeeded
<ogra> boot.scr just replaces the bootcmd in the uboot defaults afaik
<asac> it gets compiled afaik
<asac> the whole for and if stuff is not available at command prompt
<ogra> it just gets turned into a file uboot can load
<ogra> but the content is what you see in printenv at the uboot prompt
<ogra> so everything we do in .scr files should be possible directly too
<ogra> afaik you can do "if ... then ... etc" in the hardcoded bootcmd
<asac> i dont see any docs about that
<asac> if you find that let me know
<asac> uboot has really sucky documentation
<asac> http://www.denx.de/wiki/view/DULG/CommandLineParsing
<asac> bootm $addr1 || bootm $addr2 || tftpboot $loadaddr $loadfile && bootm
<asac> ogra: ^
<asac> so you can test that etc.
<ogra> well, thats already what i look for
<ogra> so we need hush shell support builtin
<ogra> aha, needs the SHELL_HUSH option set at build time
 * ogra looks in the code
<ogra> CONFIG_SYS_HUSH_PARSER :) there it is
<asac> yes
<ogra> http://paste.ubuntu.com/356511/ has the full config in case someone wants to look :)
 * ogra wonders if #define CONFIG_FEC0_PHY_ADDR	0x1F is our prob with the NIC
 * ogra builds
<ogra> asac, how about ext2 support while i'm at it, do you want that ?
<ogra> make[2]: Entering directory `/uboot-imx-2009.08/fs/fdos'
<ogra> ar crv /uboot-imx-2009.08/build/build-imx51/fs/fdos/libfdos.a
<ogra> make[2]: Leaving directory `/uboot-imx-2009.08/fs/fdos'
<ogra> hmm
<ogra> i wonder if fdos is actually the better fat filesystem :)
<ogra> mxc_fec.c: In function 'mxc_fec_initialize':
<ogra> mxc_fec.c:781: warning: passing argument 1 of 'mxc_fec_set_mac' from incompatible pointer type
<ogra> mxc_fec.c:725: note: expected 'struct fec_info_s *' but argument is of type 'struct fec_info_s (*)[1]'
<ogra> AHA !
<ogra> i guess thats the NIC issue
<asac> ogra: you can just include that i guess
<ogra> i think we should
<asac> do it
<ogra> having /boot ext2 formatted will gain us a lot more flexibility
<ogra> i.e. symlinks
<ogra> so we can have uimage being linked to uimage-$version
<asac> yes, go for it
<ogra> yup, will do
<ogra> testing hush support first
<asac> its just a config flag after all
<asac> right
<asac> hush + ext2 + fix fec
<asac> if you want me to lok at that code i can check
<asac> plars: so when did dove regress exactly? do we know that?
<ogra> asac, fec ? yeah, that would help, so i can concentrate on the script
<asac> ok ... let me use jocote ;)
<asac> ogra: that happens on current archive uboot too, right?
<ogra> gah, i hate that sshd doesnt log me out if i shut down the babbage
<ogra> asac, yea, thats what i'm building
<ogra> BBG U-Boot > setenv myload 'if mmcinfo; then echo MMC found;else echo MMC not found;fi'
<ogra> BBG U-Boot > print myload
<ogra> myload=if mmcinfo; then echo MMC found;else echo MMC not found;fi
<ogra> BBG U-Boot > run myload
<ogra> Device: FSL_ESDHC
<ogra> Manufacturer ID: 1
<ogra> OEM: 5041
<ogra> Name: SM06G
<ogra> Tran Speed: 25000000
<ogra> Rd Block Len: 512
<ogra> SD version 2.0
<ogra> High Capacity: Yes
<ogra> Capacity: 1945882623
<ogra> Bus Width: 4-bit
<ogra> MMC found
<ogra> BBG U-Boot >
<ogra> SWEET !
<asac> ogra: can you say something like:
<ogra> so now we can iterate over partitions, look for /casper etc
<asac> if fatinfo mmc 0:2; then
<ogra> sure
<asac> if fatload mmc 0:2 /boot/...; then
<ogra> well, fatls rather
<asac> ogra: where is that documented
<ogra> yeah, exactly
<asac> i didnt see that on that patge
<ogra> 14.2.16.3. Hush shell scripts
<ogra> it supports similar syntax to shell
<asac> ok
<asac> still thats not a reference
<asac> its just examples
<asac> bad doc
<ogra> well, as long as it works i dont care :)
<asac> is hushshell some wider standard
 * asac checks google
<ogra> no, its uboot specific
<asac> seems not
<asac> yeah
<asac> so ok. as long as it just works ;)
<ogra> i'm happy with if, for, while and until :)
<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
<ogra> that gives us most flexibility
<ogra> it expecially solves the prob that we have to set the UUID on cmdline after install
<ogra> BBG U-Boot > if fatinfo mmc 0:0; then echo fat found on partition0; else echo no fat on partition0;fi
<ogra> ** Partition 0 not valid on device 0 **
<ogra> ** Unable to use mmc 0:0 for fatinfo **
<ogra> no fat on partition0
<ogra> heh
<ogra> BBG U-Boot > if fatinfo mmc 0:2; then echo fat found on partition2; else echo no fat on partition2;fi
<ogra> Interface:  MMC
<ogra>   Device 0: Vendor: Man 015041 Snr 41a4343b Rev: 9.4 Prod: SM06G
<ogra>             Type: Removable Hard Disk
<ogra>             Capacity: 5743.0 MB = 5.6 GB (11761664 x 512)
<ogra> Partition 2: Filesystem: FAT16 "           "
<ogra> fat found on partition2
<ogra> cute
 * ogra goes to make some coffee and will then work out a little script :)
<ogra> hmm first i should enable ext2 i guess
 * asac grabs more coffee while ogra makes good progress
 * asac takes the cheerleader role for now
<ogra> heh
<ogra> ok, uploaded
<asac> ogra: wait ;)
<ogra> to late :)
<asac> ogra: jocote:~asac/fix_fec_warnings.patch
<asac> try that
<asac> let me know if that works, there is a bunch of odd code surrouding that
<ogra> will do
<asac> so it could well be that it doesnt and i have to fix a lot of code
<asac> but the warning is gone that way
<asac> but fec_initialize is a mystery code wise ;)
<asac> int mxc_fec_initialize(bd_t *bis)
<asac> {
<asac>         for (i = 0; i < sizeof(fec_info) / sizeof(fec_info[0]); i++) {
<asac> feels they are on crack ;)
<ogra> heh
<asac> i is used like fec_info[i]
<asac> but lets see ... if it just starts working let me know ... i can do the upload
<ogra> i'm doing a testbuild anyway so i can quickly shove that in
<asac> you were too eager ;)
<asac> but well, you probably need some uploads just to excersize
<ogra> nah, i just didnt want the changes to get lost :)
<ogra> we have anout free version numbers :)
<ogra> *enough
<asac> yeah. but if you upload quickly, it will end up with a upload failure
<asac> and the ftbfs will be stuck forever on ubuntuwire
<asac> e.g. .deb doesnt get accepted because newer source is avail
<ogra> nah, ubuntuwire is clever enough
 * ogra fires off dpkg-buildpackage ... 
<ogra> 20min or so
<ogra> i wonder if we should have other filesystems too
<ogra> ubifs, cramfs and jffs2 might be some that developers might use
<ogra> (ext2 passes btw)
<ogra> asac, mxc_fec.c passes the build with no errors now
<persia> I'd like ubifs support.
<persia> But I'm not sure I'd want a ubifs /boot, just because it'd be a pain to set up initially.
<ogra> right
<ogra> its only about /boot atm
<ogra> i wonder what would happen if i just enabled USB support :)
<ogra> something to play with on a weekend though
<persia> For /boot, don't bother about ubifs or jffs2.
<ogra> yeah
<persia> I'm less familiar with cramfs: dunno if that'd be useful.
<ogra> ext3 or 4 would be nice, but i doubt anyone ever implemented that
<persia> I *do* want to be able to put / on ubifs, but that's just a kernel thing.
<ogra> yeah
<asac> ogra: let me know if it *works*
<asac> i know that the warning is gone ;)
<ogra> heh
<persia> I'm not a fan of journaled boot.  I use ext2 even on my amd64 systems.
<ogra> will do, still building
<asac> just not sure if it works at all because there is strange code
<ogra> persia, to avoid fsck
<persia> s$boot$/boot$
<persia> fsck of 50MB is fast :p
<ogra> still slows down the boot
<ogra> especially on SD
<persia> I guess.  I can't remember the last time I needed to fsck my /boot
<asac> ogra: enable all fs that are available
<asac> unless size explodes of course
<ogra> asac, thats overkill
<persia> (but I tend to reboot only for kernel updates)
<asac> not sure how big uboot can be for flash usually
<asac> ogra: its not overkill if size is ok
<asac> otherwise stick with what we have now
<ogra> as persia said, its unlikely that anyone puts /boot on ubifs ot jffs2
<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.
<ogra> if we enable stuff it should add useful features
<ogra> USB would rock
<persia>  /boot on jffs2 basically means no kernel updates (in any sane way)
<persia>  /boot on ubifs could be made to work, but it'd be a very ugly hack.
<ogra> iots like squashfs, isnt it ?
<ogra> you would have to recompress it each time
<persia> jffs2 is like squashfs
<persia> ubifs is just different.
<ogra> (for a user perspective i mean)
<asac> dont care. if we have reasons against those - and uboot bin gets bigger it can be ignored
<persia> There's a procedure to create an initial filesystem, but writes thereafter are persistent.
<asac> i want usb-storage ;)
<asac> thats more important
<ogra> uboot.bin gets surely bigger with each option i enable
<persia> Yes.
<ogra> and musb :)
<persia> usb-storage is essential
<ogra> but according to FSL it doesnt work
<persia> Depends on who you ask.
<ogra> i'll tinker with it in a spare minute some day
<asac> they dont have the code for uboot there yet
<asac> only thing i found was support for some fsl powerpc stuff
<ogra> well, should be only the driver init
<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.
<ogra> USB generally is in uboot
<asac> i know
<asac> see yourself. support isnt there imo
<ogra> yes
<ogra> but there is a kernel driver
<ogra> most uboot drivers are just based on kernel drivers
<persia> ogra: Which means you can port it on saturday ? :)
<plars> asac: no, that's why I was wondering if tobin might know
<ogra> nah
<ogra> i'm no kernel hacker
<ogra> but i can take a look :)
<asac> plars: i remember that we had working dove images
<asac> then at some day you said it broke
<ogra> plars, well, according to isotracker tobin didnt test dove at all
<ogra> did we have dove for A1 ?
<ogra> iirc we didnt
<ogra> asac, no go
<ogra> still comes up with a MAC of 00:00:00:....
<ogra> SIOCSIFFLAGS Cannot assign requested address ... is what ifconfig gives me on ifconfig eth0 up
<ogra> i guess we need FSL help here
 * ogra hugs his USB NIC
<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.
<dmart> s/lp bug in/lp bug on/
<ogra> dmart, Bug #385553 ??
<ubot4> Launchpad bug 385553 in pixman "Integrate NEON optimisations for armel" [Wishlist,Fix released] https://launchpad.net/bugs/385553
<ogra> we could recycle that one i assume
<asac> ogra: yeah. i assume the code is completely busted
<asac> it looked really bad hackish
<dmart> What code?
<ogra> asac, the fun thing is that it defaults to tftpboot
<asac> ogra: the mcx_initialize function
<ogra> dmart, different issue :)
<asac> dmart: the uboot fec driver has odd stuff
<dmart> Oh, right :)
<asac> seems they moved to an array approach, but only did so at half of the places
<asac> like:
<ogra> dmart, seems FEC doesnt get initialized at all when using uboot
<asac> 13:48 < asac>         for (i = 0; i < sizeof(fec_info) / sizeof(fec_info[0]); i++) {
<asac> and then they use fec_info[i]
<asac> is that going to work?
<ogra> dmart, leaving us without NIC since the kernel cant figure out a MAC for it
<asac> e.i would have expected it to be more like sizeof(struct fec_info_s)
<dmart> doesn't look right
<asac> it looks completely wrong ;)
<ogra> dmart, you boot with an older uboot, right, do you have NIC support on your babbage ?
<asac> esepecially since the fec_info array is a constant array
<ogra> (we might just be able to roll back to an older patch)
<asac> that doesnt grow
<asac> it should just be i < 1 ;)(
<asac> let me check
<persia> Does the NIC work if a MAC is just arbitrarily assigned by userspace later?
<dmart> It was on a nettop, and I don't remember whether the network was OK... I didn't check that.
<ogra> persia, nope
<persia> Ugh.
<ogra>  SIOCSIFFLAGS Cannot assign requested address
<ogra> no matter what i do
<persia> NIC not promiscuous?
<ogra> the HW isnt completely up
<ogra> we had such issues before with redboot
<ogra> in jaunty iirc
<asac> ogra: get the new patch from same location
<ogra> let me first try something
 * ogra issues setenv ethaddr 00:04:9F:00:E8:C2
<asac> ogra: the _initialize code doesnt initialize anything without that patch
<asac> sizeof(fec_info) / sizeof(fec_info[0]) is probably 0
<asac> so no device gets initialized
<ogra> yeah
<ogra> but uboot reports FEC0 as primary interface
<asac> yes
<ogra> so it knows its there
<asac> ogra: it knows about it, but doesnt initialize it
<asac> because the loop isnt entered
<ogra> yes, thats why i try to check if initialzing it manually changes a thing
<asac> no
<asac> you cant initialize it manually
<asac> because the code that initializes it does nothing ;)
<asac> unless you can run C code at the prompt
<asac> at least i would try that patch first ;)
<asac> e.g. the drivers vtable isnt filled if it really doesnt go in there
<ogra> same patch name ?
<asac> yes
<asac> hmm. if it knows the name it seems to have happened. but try anyway
<plars> ah cool, alternates got added to iso tracker today
<asac> yeah
<asac> so i think that is probably 1 ;) ... too bad
<asac> do you see any other errors ogra ?
<ogra> just applying the change ...
<ogra> one sec, cdbs-edit-patch isnt the fastest on the babbage :)
<asac> ogra: copy the patch in there
<asac> ogra: you should use quilt
<ogra> asac, the package is 100% cdbs
<ogra> and i wont touch quilt if i dont have to
<ogra> its the biggest pain in the ass i've encountered after git
<asac> just replace the patch then :)
<asac> oh wait, then it fails to clean
<asac> hmm. quilt doesnt have that problem ;)
<asac> ogra: if you are still at it, grab a new version of the patch that enables debugging
<persia> CDBS simple-patchsys doesn't have that problem either.
<ogra> ARGH!
<asac> fact is that simple-patchsys is for the weak ;)
<ogra> did you notice there is fec_mxc.c and mxc_fec.c in the drivers dir
<ogra> insanity !!!
<asac> really. the one i touched at least gets compiled ;)
 * asac checks
<persia> Well, someone decided that simple-patchsys was the easiest to teach, so lots of interesting packages end up using it.
<asac> yes, but for professional development - aka if you really fix bugs and touch code - its inferior ;)
<asac> throwing existing patches together is simplest yes
<asac> but rebasing patches that dont apply anymore is a mess ;)
<ogra> building
<persia> Depends on one's viewpoint.  I also like quilt, which makes me a poor candidate as a simple-patchsys apologist :)
<ogra> another 20min ...
<asac> often there are viewpoints/opinions ... but in this case there are only facts :-P
<asac> ogra: make O=debian/build-*/
<asac> then debuild -nc
<ogra> dpkg-buildpackage -b
<ogra> i want a proper package to work with
<asac> yeah. thats why it takes 20 instead of 2 minutes
<asac> debuild -nc gives you a good package if you just change one patch
<asac> ok
<asac> me hopes the other fec source isnt used
<ogra> me too :)
<ogra> but given that the warnings go away after your first fix it doesnt look like
 * ogra takes a coffebreak
<asac> ogra: i would abort the break. the enabling of debug fails to build
<asac> what a bad code :(
<ogra> asac, to late to abort it :)
<ogra> asac, no change
<asac> ogra: so you didnt pick the DEBUG change?
<asac> ok
<asac> well. then...
<ogra> no, i just picked the fec change
<asac> i updated that a minute after you picked it ... thats why i am not sure
<ogra> oh, bte, we'Re at 152k for .bin
<ogra> vs 136k before switching on ext2 and hush
<ogra> *btw
<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)
<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
<ogra> sihg, is there any way to disable DCC offers in xchat ...
<ogra> that spam is driving me insane
<ogra> NCommander, do you happen to know if there is any way of command substitution in hush shell ?
<NCommander> ogra, define command substitution
<ogra> files=$(fatls mmc 0:2)
<NCommander> ogra, yeah, you set the command you want in a variable and then run it
<NCommander> i.e.
<NCommander> setenv testcmd fatls mmc 0:2
<NCommander> run testcmd
<ogra> an that gives me the flie list in the files variable ?
<NCommander> ogra, oh, no
<ogra> i want a variable i can work with
<NCommander> ogra, can't do that unfortantely
<ogra> right, thats what i thought
 * NCommander notes hush is very limited
<ogra> yes, found that :)
<dmart> How about:
<dmart>  setenv tmp mmcload ${file}
<dmart> run tmp
<dmart> (hang on, are you still talking about UBoot?)
<ogra> yes :)
<dmart> Something like the above might work then
<ogra> what i want is some way to detect if uimage exists in a partition/dir
<ogra> but i have no grep and fatls is pretty noisy
<NCommander> ogra, what I did for dove is just try and unconditionally load the boot.scr file
<NCommander> ogra, if that fails, then assume the uimage is MIA, and move on
<ogra> "fatls mmc 0:2 uimage" unfortunately doesnt work
<dmart> That might work
<NCommander> I dunno if fatls/ext2ls return an error code
<NCommander> ogra, it should work ...
<NCommander> That does work on Dove I think
<ogra> doesnt here
<NCommander> *grummmmmmble*
<ogra> BBG U-Boot > fatls mmc 0:2 uimage
<ogra> No Fat FS detected
<ogra> BBG U-Boot > fatls mmc 0:2
<ogra>   3085760   uimage
<ogra>   3282905   uinitrd
<dmart> ?
<ogra> it somehow interprets the last parameter
<dmart> Hmmm, not sure I ever tried that
<NCommander> ogra, try fatls mmc 0:2 /uimage
<dmart> What does help fatload say?
<ogra> it says the last param is a directory :P
<ogra> BBG U-Boot > fatls mmc 0:2 /
<ogra>   3085760   uimage
<ogra>   3282905   uinitrd
<ogra> so yes, that works
<ogra> but i still dont know if uimage exists
<ogra> since i cant parse the return value
<dmart> What 's the end goal heer?
<dmart> s/heer/here/
<ogra> i want to loop over all fat and ext2 partitions and find if there is a boot.scr
<ogra> if boot.scr and uimage exist i want to load boot.scr and execute it
<Sarvatt> hmm arm SIMD fast paths are disabled in the pixman in lucid
<NCommander> ogra, look at how I did it on Dove, and rewrite :-)
<NCommander> ogra, I only check for boot.scr and not uImage
<ogra> boot.scr then should have all env variables needed
<dmart> Is there a way only to iterate over partitions that exist, or do we have to be dump and poll everything (slow?)
<dmart> argh s/dump/dumb/
<NCommander> dmart, the later, but it isn't too bad, only 3-4 seconds on Dove boot time
<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
<ogra> dmart, ^^^ that works fine
<ogra> and isnt to slow
<NCommander> ogra, http://paste.ubuntu.com/356625/
<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
<dmart> Can we do something like for ...; do if <script exists>; then <run script>; break; fi; done ?
<ogra> dmart, yes
<dmart> Then if we hit the script in an early partiton (likely) we don't have to do the whole search
<ogra> the prob is <script exists>
<dmart> Right
<ogra> you can only blindly load
<ogra> thats what NCommander does in the pasted script
<dmart> What about mfill will garbage; load script; run script
<NCommander> ogra, we could extend u-boot and give it more of a brain
<dmart> If no script was loaded, the memory will still be garbage with no headers and the next command will be run.
<ogra> NCommander, i just added 20k to the babbage one, i dont want it to grow to big
<ogra> also i'm probably to cautious, NCommander's way works ...
<NCommander> ogra, u-boot is frustatingly limited in places you don't want it to be
<ogra> yes
 * NCommander isn't super happy with the code itself, but it does get the job done.
<ogra> right
<ogra> and i only have mmc atm ... so it would be a lot smalled for me anyway
<ogra> *smaller
<dmart> Is there some way we can push the complexity out of the bootloader scripting?  Maybe saving things in the U-Boot environment area?
<ogra> thats what boot.scr is for
<ogra> for babbage i'll just set the right defaults
<dmart> Maybe it would be easier just to implement the search in C after all, though I guess that's a last resort.
<ogra> boot.scr will then contain loadaddr and cmdline as well as the lioad and bootm commands to get kernel and initramfs
<ogra> the loop script will live in the bootloader defaults, boot.scr should only be a few lines for the above
<NCommander> dmart, well, the boot.scr mechanism was a last minute hack to have a sane boot on dove
<ogra> the important part here is that you dont need serial access, just edit boot.scr and run mkimage on it
<dmart> Sure; I was using the same approach when playing with the nettops
<ogra> but boot.scr should be limited to the bare minimum
<ogra> and uboot should still work if you put it into flash
<ogra> so i need to find the right level of complexity for either side :)
<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.
<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
<ogra> thats not to complex
<ogra> it gets more complex if i start to look for /casper though
<ogra> i guess i could even drop the fatls
<ogra> for i in 1 2 3 4 5;do if fatload mmc 0:$i ${loadaddr_script} boot.scr;autoscr ${loadaddr_script};fi;done
<NCommander> dmart, well, its probably easier to extend the commands we need
<dmart> Maybe... just a thought
<ogra> i wonder if $i is still respected if i do setenv myloadscript 'fatload mmc 0:$i ${loadaddr_script} boot.scr'
<ogra> then i'd end up with: for i in 1 2 3 4 5; do if run myloadscript; autoscr ${loadaddr_script};fi;done
 * ogra tries that
<ogra> hmm, no, it doesnt take $i
<ogra> HA !
<ogra> setenv myloadscript 'fatload mmc 0:$i ${loadaddr} uImage'
<ogra> for i in 1 2 3 4 5;do run myloadscript;done
<ogra> thats works fine
<NCommander> ogra, neat. Isn't the lack of documentation on how this all supposed to work semi-annoying? :-/
<ogra> yeah
<ogra> http://paste.ubuntu.com/356637/ seems to work fine
<asac> ogra: we never look at mmc 1:* ?
<ogra> do you want me to ?
<asac> not sure if that makes any practical sense
<asac> atm probably not
<asac> but who knows ;) ... in theory we want to check all devices that are available
<ogra> right, i think the babbage can only boot from 0
<asac> that includes mmc, usb
<ogra> indeed
<asac> yeah. but 1 doesnt appear.
<asac> so in case something supports 1 it would just work.
<ogra> but there is only one mmc and no usb :)
<asac> your decision ;)
<ogra> we can modify
<ogra> i want a case for now where /casper and / both work
<asac> i think it wouldnt hurt ... but sure, better work on the directory thing
<ogra> and / being preferred, casper being second choice
<asac> yeah
<asac> ogra: how do we do the root=?
<ogra> from boot.scr
<asac> maybe we shoudl really go for boot.scr directly
<ogra> i'm not at that point yet
<asac> ah ok. so we do that in first iteration ;)
<asac> hehe
<ogra> right
<asac> fine
<ogra> i'm only playing with the shell capabilities atm
<asac> everything works ;)
<ogra> gah ... i winder why it hangs now ... silly me
 * ogra forgot mmcinfo
<asac> which is kind of dubious ;)
<asac> what thats needed
<asac> maybe we can fix that to run lazily on demand
<ogra> as default i'D say
<ogra> http://paste.ubuntu.com/356641/
<ogra> :D
<ogra> god
<ogra> is anyone else getting tons of DCC offers today ?
<ogra> my screen gets spammed all the time here
<asac> dmart: ok
<asac> ready ;)?
<asac> seems like some good guy entered most rdepends ;)
<asac> hmm ... thats bad
<asac> good bye
<ogra> heh
<ogra> you scared him
<asac> we had a date
<asac> ;)
<ogra> itym "an appointment"
<ogra> *g*
<asac> yep
<plars> alternates seem to be failing in several places, sounds similar to what NCommander was describing I think (this is on dove atm)
<ogra> unless you planned to bring roses :)
<asac> that was the joke ;)
<asac> plars: NCommander said they work (probably imx)
<NCommander> plars, I was able to get a completed install on dove, but its very twichy
<plars> NCommander: I get an error installing the base system (debootstrap warning) that there was an error configuring packages (continue seemed to work ok)
<plars> NCommander: then at the end, the "select and install software" step fails and takes me to the menu
<plars> NCommander: is that what you saw as well?
<ogra> plars, whats the build date ?
<NCommander> plars, it depends on the build. Tuesdays build worked without issue except I had to repeat the select a& install software phase
<plars> ogra: it's the current one, just synced it this morning
<ogra> debootstrap not finishing is bad and usually indicates that something was out of sync when the image was rolled
<plars> ogra: 14.1
<asac> repeat select and install? strange that it started working on second attempt
<ogra> oh, how do you set something to "started" on the tracker
<asac> maybe apt cache isnt updated in first run
<plars> ogra: new feature :)
<asac> ogra: you can say INPROGRESS
<ogra> yeah, intresting :)
<plars> ogra: it's another option besides pass or fail
<ogra> asac, on the isotracker ?
<asac> ogra: but thats voluntarily and doesnt show up on the graphs
<asac> ogra: ah ... no. i think thats not wanted
<ogra> oh, right, i see it in my list :)
<asac> as folks might start ... dont submit and others think its well covered
<ogra> yeah,m its an odd feature
<asac> they really added that?
<ogra> yes
<ogra> http://iso.qa.ubuntu.com/qatracker/result/3575/385
 * asac should have stayed more in touch with QA team
<ogra> its adds a little clock next to the tester too
<asac> ok. that was discussed as a potential way, show it for 1-2 hours
<ogra> Result : *	Passed Failed Started
<asac> dmart: welcome back ;)
<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'
<ogra> dmart, he has roses for you he said :P
<plars> asac: so if they flagged it yesterday, you can assume they hit a roadblock, or something is preventing them from completing
<dmart> hmmm
<dmart> IRC troubles
<dmart> asac, did you want to carry on with the package list review
<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
<asac> dmart: that was the idea. we can do that tomorrow at 10 UTC if you want
<asac> yeah
<dmart> asac: Now should be OK for a bit. IRC seems to be working again for me
<plars> better to have one person testing each thing in parallel, than 10 people testing the same thing when time is short
<asac> plars: yeah true. i always was optimistic that we could motivate a big crowd of testers
<dmart> Has anyone else experienced possible Ethernet autonegotiation issues with Babbage boards attached to hubs?
<ogra> dmart, only poweroff issues
<ogra> and only on the B2.0
<asac> dmart: ok lets get started if you want
<asac> had to get the files first again
<dmart> ogra, we can pursue that later
<dmart> asac: OK
<asac> https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList
<asac> gmp
<asac> is where we stopped it seems
<asac> uses mov ...
<dmart> ogra, can you point me to something that explains what rootstock is?
<ogra> hmm
<ogra> https://wiki.ubuntu.com/ARM/RootfsFromScratch isnt enough ?
<asac> gnome-pilot
<dmart> asac: add     r2, pc, #invtab-.-8: looks like it assumes ARM and needs looking at
<ogra> https://launchpad.net/project-rootstock/ has some explaining text at the top
<lool> ogra: Did you manage to merge the rootstock branches yesterday?
<asac> false positive
<asac> dmart: gmp?
<ogra> lool, sorry, no, doing that now
<asac> ok
<asac> updated
<asac> gnome-pilot is false positive
<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.
<asac> graphviz:
<dmart> asac: yes
<asac> also false-posiitive
<asac> same for installation-guide ;)
<asac> good
<asac> libatomic-ops  and liffi are next
<dmart> darn... variables called "strex" :P
 * asac wonders if atomic-ops should already have the right code
<ogra> lool, merged and pushed
<ogra> lool, sorry for the delay
<ogra> oh, you split the work on two branches ...
<asac> dmart: libffi already has the bx ... agree?
<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.
<asac> hmm.
<asac> ok lets mark for review
<ogra> lool, second one merged as well
<asac> dmart: http://paste.ubuntu.com/356654/ thats what libffi does imo
<dmart> asac: if that's the only hit in libffi it looks OK
<asac> i think so:
<asac> search-arm-mov.filt: ./libffi-3.0.9~rc3/src/arm/sysv.S:# define call_reg(x)	mov	lr, pc ; bx	x
<asac> search-arm-mov.filt: ./libffi-3.0.9~rc3/src/arm/sysv.S:# define call_reg(x)	mov	lr, pc ; mov	pc, x
<asac> search-arm-mov.filt: ./libffi-3.0.9~rc3/src/avr32/sysv.S:    mov     pc, lr
<asac> those are the hits
<asac> libgc: false-+
<dmart> Are you sure:   __asm__ __volatile__("swp %0, %2, [%3]"
<asac> hmm
<asac> let me grep again
<asac> you are right
<asac> i am on crack ;)
<asac> i grepped for two in a row and looked at libgd-gd2-perl
<dmart> AH
<dmart> (sorry, caps lock)
<asac> libgd2 -> false+
<dmart> yes, looks like it
<dmart> (both libgd2 and libgd-gd2-perl)
<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 ?)
<asac> libmad
<asac> tha tis
<dmart> Simililar to gmp, it looks like it assumes ARM and needs a closer look
<asac> libpst:
<dmart> false-+
<dmart> I think
<asac> yeh
<dmart> Same for libwoodstox
<asac> libwoodstock-java hopefulyl too
<asac> checking
<dmart> I think we can ignore linux-*: this is for the kernel maintainers.
<asac> linux -> not covered
<asac> yeah
<asac> filling that up
<asac> llvm
<dmart> linux86: is separate: it's an x86 assembler, so false-+
<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
<lool> ogra: thanks
<asac> yeah i marked all linux* as not covered
<asac> hmm. llvm-gcc isnt in the table
<asac> only llvm. did you treat them as one dmart ?
<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
<dmart> What is llvm-gcc?
<asac> one sec
<asac> Meizirkki: grepping for llvm gives things like:
<asac> dmart: ^^
<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.  */
<asac> llvm-gcc isnt in the table afaics ... adding
<dmart> Ah... it's in universe
<dmart> scroll down
<asac> really? i scrolled down
<asac> ok
<asac> missed it most likely
<asac> ok mono is next
<asac> needs investigation. they use atomic stuff
<dmart> Yes, plus "mov pc, lr" type stuff which might not work in Thumb-2.
<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
<dmart> nasm - false-+ (another x86 assembler)
<asac> dmart: nasm is marked as x86 only in the table
<asac> yeah
<asac> ncurses
<plars> but I do see that ureadahead and plymouth seem to be having problems
<asac> luckly false+
<asac> newlib
<dmart> not sure; do we know what uses it?
<asac> -> investigate mov's
<asac> hmm
<asac> newlib is mared as having 0 rdepends
 * asac wonders if that is true
<asac> runtime depends 0
<asac> on libnewlib0
<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... ?
<asac> yeah. i added "investigate if its used"
<asac> ocaml
<dmart> newlib - It looks like the affected code is on places like crt0.S where it may not be a problem.
<asac> hmm ok
<asac> ill add that comment
<dmart> ocaml - I guess that needs a look.
<asac> yeah
<asac> seems jocaml uses a code copy
<asac> openbabl doesnt even have a a hit for me
<asac> oh
<asac> openbabel ;)
<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",
<asac> that doesnt look like asm
<asac> openjdk-6 needs a loog -> doko
<asac> openssl seems ok
<asac> only armv4 source files affected
<asac> pho:
<asac> php:
<dmart> openbabel - agreed
<dmart> openjdk-6 - agreed
<asac> false+ (php5)
<asac> pixman ...
<dmart> openssl - someone should take a quick look to make sure the armv4 files are not still used when building for newer arches
<asac> hmm. you are tough ;)
<asac> we already have enough work :-P
<asac> but ok
<dmart> Hopefully that's a quick check...
<asac> search-arm-mov.filt: ./pixman-0.16.2/pixman/pixman-arm-detect-win32.asm:    mov pc,lr
<asac> yeah
<asac> that one probably needs to be checked
<asac> though i would hope we can ignore win32 ;)
<dmart> pixman should be a quick review too, since that's being actively maintained
<dmart> php5 - agreed false-+
<asac> postgresql -> the atomic thing is fixed in bzr ...
<asac> yes
<dmart> GCC atomics?
<asac> yes
<dmart> cool
<dmart> procps - false=+
<dmart> ps3-kboot - not relevant (bootloader)
<dmart> pulseaudio - should be checked for SMP-safety
<dmart> (maybe port to atomics)
<asac> python is owned by doko ;)
<ogra> he
<ogra> e
<ogra> h
<asac> but i think they use the same macros
<asac> for call_reg
<asac> so its probably ok
<asac> but i will note those as to chcek by doko
<asac> qemu-kvm
<dmart> Yep.  Looks like it may be OK, but worth a check.
<dmart> (python*, that is)
<ogra> qemu-kvm is a mess anyway wrt nonn x86 compatible binaries
<asac> not sure what to do with qemu
<ogra> nothing
<ogra> it should go into PAS since ages
<asac> i think i will note down that lool checks that ;)
<asac> ogra: we look at the asm code ;)
<ogra> yes, but if you dont buiuld for != x86 who cares ?
<asac> qt-x11-free
<dmart> qemu has a swp-based atomic which can hopefully be ported to GCC atomics.  The rest looks like disassembler code.
<asac> ok adding that
<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
<dmart> false-+? (looks like x86 asm)
<asac> yeah
<asac> wow
<asac> qt4-x11 has a webkit copy :(
<dmart> Ugh
<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)
<dmart> Also, I'd alread raised a bug #490371
<ubot4> Launchpad bug 490371 in qt4-x11 "Atomic operations not safe for ARMv7,Thumb-2 and multicore" [Medium,Triaged] https://launchpad.net/bugs/490371
<asac> i think its safe to ignore reboot-imx ... thats most likely build for arm5
<asac> ogra: ?
<ogra> yes
<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)
<asac> dmart: thanks. noting
<dmart> redboot - agreed: bootloaders don't run SMP, and we'd already know if it didn't work on imx51 ;)
<ogra> lool, i know ... we had that discussion before :)
<lool> https://buildd.debian.org/build.php?arch=&pkg=qemu speaks for itself
<asac> sg3-utils
<asac> search-arm-swp.filt: ./sg3-utils-1.28/src/sginfo.c:    bitfield(pagestart + 10, "SWP", 1, 2);
<asac> hmm
<dmart> false-+ ?
<asac> lets hope
<asac> swig1.3
<asac> same
<dmart> YES
<dmart> argh... "yes"
<asac> syslinux -> ignore
<dmart> agreed
<asac> texlive-bin
<asac> x86
<asac> thunderbird -> covered by firefox
<dmart> Also false-+.  I'm surprised how often strex is appearing as a variable name...
<dmart> (texlive-bin, I mean)
<asac> though we might need xulrunner 1.9.2 backport as tbird 3.0 uses 1.9.1 afaik
<asac> unles 3.1 comes out soonish
<asac> dmart: texlive-bin is also x86 asm
<dmart> If the xptcall stuff shared then... will bug fixes propagate?
<asac> ok just a couple left ;)
<dmart> texlive-bin - oh, right
<asac> dmart: yes
<asac> they use a xulrunner copy (unmodified)
<asac> unzip
<asac> acorn ... does that apply?
<dmart> Umm, probably not. It looks like very old, possibly pre-ARMv3 code.
<asac> yeah. just curious if someone would keep acorn name
<asac> lest assume so
<dmart> I'll take a quick look but we can probably ignore
<asac> upx-ucl
<asac> needs a look ;)
<asac> vim
<asac> search-arm-mov.filt: ./vim-7.2.245/src/swis.s:movspc,lk
<dmart> upx-ucl: probably. What is this package?
<asac> no ide ;)
<asac> for webkit we already know we want to check
<asac> xen -> ignore ?
<asac> xine-lib i dont know.. please check
<asac> zip is last:
<dmart> "UPX is an advanced executable file compressor", apparently
<ogra> another zipper :)
<dmart> xen is probably out of scope right  now
<asac> also acorn ;)
<asac> yeah... xen isnt working at all afaik
 * ogra would put it under "linux"
<asac> so vim and xine-lib are the last too
<dmart> vim - hold on, I'll take a look; probably not relevant.
<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.
<asac> yeah. so i saved the wiki. xine-lib is last to fill in in main ;)
<asac> well done!
<asac> now someone needs to file bugs ;)
<asac> or first fix wiki syntax ... doing that
<asac> ok done
<asac> lets continue later ... have to run to a call :)
<dmart> I will probably disappear now... catch you tomorrow
<dmart> Thanks
<asac> sure
<asac> enjoy
<ogra> dinner !!!
<ogra> see^Whear you at the call
<dmart> bye guys
<NCommander> plars, alternate installer passed on dove
<NCommander> (very slow)
<plars> NCommander: did for me too, but fails to come up correctly (same bug with X we saw on desktop)
<plars> NCommander: you didn't have to retry a lot?
<plars> well, not a lot
<plars> just twice really
<plars> once continue because it failed debootstrap attempt configuring  base packages
<plars> then again when select and install software step failed, had to go back to the menu and retry that (which worked it seems)
<plars> imx51 one seems to be completely stuck here, and I don't see a way out
<plars> not hung at least
<NCommander> plars, checks vty4
<plars> right, I have unpacking openoffice.org-common
<plars> for the last 1+ hours
<plars> NCommander: not seeing anything useful in syslog, is there a debug mode with alternates?
<NCommander> plars, /var/log/installer.log
<plars> NCommander: nope
<plars> NCommander: syslog, media-info, and partman are the only logs there
<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
<asac> +rev><chip rev>"
<asac> plars: tugess you already knew that (for system information /test)
<asac> guess
<plars> asac: I'm already gathering /proc/cpuinfo
<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)
<asac> yeah
<asac> i know
<asac> yeah.
<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
<asac> yes. thats what i suggested too
<asac> for now
<asac> depends on how important that info is
<plars> asac: it's nice to have, but can be gathered other ways
<asac> just wonder whta use it would be, most likely if uboot is the problem, the system doesnt boot at all
<asac> so you cant gather that that easily
<asac> plars: for you bug 495171 is gone, right?
<ubot4> Launchpad bug 495171 in linux-fsl-imx51 "USB errors while installing" [Undecided,New] https://launchpad.net/bugs/495171
<plars> asac: correct, I am no longer seeing that one
<asac> ok i will close it then
<asac> done
<asac> ;)
<asac> actually ... now that i look at it, it looks exactly like the issues i get when trying use my usb-storage thing
<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.
<asac> guess i should rather open a new bug if your hardware doesnt have that
<RaffoPazzo> i don't think that the packages available by rootstock are optimized...
<RaffoPazzo> i'm i wrong ?
<asac> in general we dont optimize for neon, some packages use hwcaps though to use optimized code
<asac> dont ask me which ;)
<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
<asac> plars: have you tried to fix dove  by using an older kernel?
<asac> NCommander: ^^?
<RaffoPazzo> but i guess i should use gentoo if i want everything optimized....and i would not..roostock is so useful ^^
<asac> NCommander: https://edge.launchpad.net/ubuntu/+source/linux-mvl-dove/2.6.31-701.4
<asac> that one i guess
<armin76> :D
<asac> oh
<asac> https://edge.launchpad.net/ubuntu/+source/linux-mvl-dove/2.6.31-701.3
<asac> that one NCommander ^^
<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
<RaffoPazzo> is theere a way i can see on which architecture a package was compiled on ?
<armin76> RaffoPazzo: lucid is all armv
<armin76> 7
<RaffoPazzo> tnx
<asac> plars: do we know that it worked at some point with that kernel?
<asac> given that everyone was on vacation etc. i would say no
<plars> asac: right
<asac> so before speculating, we should test the kernel ;)
<plars> asac: GrueMaster, which was why, I think GrueMaster was going to try some of the images he has archived
 * armin76 offers to test the kernel *g*
<asac> ok cool
<plars> I can try *just* swapping the kernel if needs be though
<asac> GrueMaster: what images do you have archived for dove?
<asac> plars: that would be good imo
<asac> i think we definitly know that we had working images with the kernel before
<asac> so if that doesnt fix it, we know at least that the kernel alone isnt busted
#ubuntu-arm 2010-01-15
<persia> So, I think I figured out how to make plymouth work on armel, at least for ATI or nVidia cards.
<persia> But someone needs to write KMS drivers for more typical video adaptors if it's really going to work for most folk.
<rcn-ee> hey persia what do you need? omap's have dss2 which went mainline in 2.6.33 which might work...
<persia> rcn-ee: From what I'm told, I need a KMS driver, and then someone to write something likehttp://cgit.freedesktop.org/plymouth/commit/?id=f2048af97dcc862dbbb587a0cc2546ddbdbd2b0c that works with the KMS driver.
<persia> And preferably something that can build and (kinda) work on all architectures, so we don't have to special-case it.
<persia> Mind you, some cases won't get much testing (like I'm building libdrm-intel for armel right now)
<persia> Note that the results of this will probably either require some customisation or more maturity of Ubuntu armel, just because with the current way arm kernels boot, only a couple dev boards get supported, which means very little chance of working drivers for fancy graphics chips.
<rcn-ee> very true....  which reminds me, it would be nice if meta packages had 'arch' support, no need for ati/intel/nvidia stuff for armel...
<persia> But getting the code written and into linux and plymouth makes it easy to get working once the hardware is there.
<persia> Actually, metapackages *do* have per-arch support.
<persia> But I disagree with your assertion.  I own an ARM device (sadly ARMv5) that has an ATI graphics accellerator.
<persia> And I know there exist ones with nVidia chips.
<rcn-ee> yeah, that's right the msm7200 has one..  (we almost started stocking that one..) and nvidia's tegra...
<persia> Dunno if the current radeon and nouveau drivers work for those, but we may as well publish packages and maybe someone will find a bug and fix it :)
<oyotat> Hello. Does anyone know if ubuntu-arm would run on a Gumstix Xscale? like a Gumstix Basix?
<persia> oyotat: I can say that you'll probably need a custom kernel, at least.  Let me check the gumstix site.
<rcn-ee> actually plymouth's framebuffer mode should work, i need to test that tomorrow.. (dss2 sets the resolution at boot)
<persia> rcn-ee: I don't know if I will get the necessary bits into the archive by tomorrow, but in short: build libdrm-intel for armel, then build plymouth using that libdrm-intel1-dev.
<oyotat> persia, thanks. one last question, anyone happen to know what's the difference between a marvell armada xscale like the pxa1xx versus the older intel xscale like pxa270?
<persia> You end up with a currently-useless intel driver for plymouth, but it lets you test.
<persia> oyotat: You should be able to run Jaunty on a verdex-based system with a custom kernel, and up through lucid on an overo-based system with a custom kernel.
<persia> Dunno which is "Basix".
<rcn-ee> oyotat, pxa270 i think are only armv4 based...
<persia> I'm fairly sure they are ARMv5
<persia> Because some of the pxa26x series were ARMv5
<persia> But I could be mistaken.
<rcn-ee> yeah they are armv5, + intel instructions... they were just weird...
<persia> Well, one can ignore the instruction extensions to make something work :)  My collection of Zauri have been happily doing their thing for some time (although I find that, despite the better form-factor, I have replaced all my use cases with the Netwalker)
<persia> Err, maybe I should have written "despite the inferior shape"
<persia> (Zaurus case >> Netwalker case but Netwalker chips >> Zaurus chips)
<Sarvatt> if anyone wants to try a newer pixman with more neon optimizations out -- http://sarvatt.com/downloads/armel/lucid/
<ogra> mumble
<ogra> so i cant load boot.scr for no apparent reason :/
<xreal> Hi there. Is it even possible to run Linux on a PNA with ARM-compatible CPU?
<persia> xreal: What's a PNA?
<ogra> picking nose appliance ?
<xreal> persia: Personal Navigation Assistant
<persia> xreal: Well, there's probably three factors you'd need to investigate.
<xreal> persia: Okay, which ones?
<persia> 1) Which instruction set is supported by the processor: if it's new enough, you may be able to run Ubuntu
<xreal> persia: http://pdadb.net/index.php?m=cpu&id=a9g3&c=centrality_atlas_iii
<persia> 2) Is there a way to boot an arbitrary kernel and run against an arbitrary filesystem : if the device is hackable, you may be able to run Ubuntu
<xreal> Instructions: 	 ARMv5TEJ
<persia> For that instruction set, you could only run Ubuntu 9.04.  Newer versions will not run.
<xreal> persia: I've talked to the manufactor and he can offer me a "clean" device, without any software.
<persia> 3) Can you build (or find) a kernel that supports Ubuntu 9.04 userspace that runs on the device.
<xreal> persia: I think 4) will be: is the other hardware support, like graphics, touchscreen etc.
<persia> 4) Are there sufficient drivers for the available input/output devices to make it worthwhile?
<persia> Yep :)
<persia> But the first three are the key ones.
<xreal> I think, I will stay on WM5 and will code software for Windows Mobile.
<persia> And 4) is kinda just personal style.  Some people would like to run Ubuntu on their toaster, even if the entire interface consists of a lever one pushes down, which pops up when the toast is done.
<xreal> I wanted to use Linux on the device and code linux software ... but that's too hard to figure out.
<ogra> that really depends on your toaster !
<persia> ogra: Well, sure.  If you have a cool toaster, there might be a point.
<ogra> i do !
<xreal> I'm not that deep into linux...
 * ogra got a cool toaster for chriatmas 
<ogra> *christmas
<persia> On the other hand, I've found that the smarter an appliance I have, the less likely I can use it successfully.  The processor on my rice cooker died, and now I can make rice reliably.
<persia> Which one?
<ogra> http://fs1.kauflux.de/slot/358/artimg/large/13226207_401557.jpg
<persia> blinkenlights!
<ogra> hehe
<persia> So, did you install Ubuntu?
<persia> Or does it come pre-installed?
<ogra> nope, sadly not ... still working on an installation toast :)
<ian_brasil> that sir is an impressive toaster
<ogra> heh
<persia> What due the dark spots beside the slots do?
<ogra> they hover out the breadroll device
<ogra> it slides out if you touch them
<persia> So you can slow-roast stuff over the toaster?
<ogra> right
<persia> Wow!
<ian_brasil> that rocks
<ogra> it also has a freezer program to thaw frozen toast
<persia> Does it auto-toast once the bread is defrosted?
<ogra> yep
 * persia should really put on an op hat and declare this off topic, but deep fascination wars with this instict
<ogra> lol
<persia> That's just a really nice toaster.
<ogra> it is, was my only item on the whishlist this year :)
<koczis> hi all, anyone interested in ARM/Cortex talk? - have a few questions... rather regarding hardware, but... , anyone?
<persia> !ask | koczis
<ubot4> koczis: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<koczis> self-introducing and the subject may be handy - especially when group subject isn't really in sync...
<koczis> I have questions about interrupt handling and interaction between Cortex Core and peripherals in STM32
<koczis> the 1st is: do I have to clear pending flags early or lately
<koczis> ?
<persia> Hrm.  You might have to wait for some time to pass to get an answer to something that specific.
<persia> Most of what we've been doing is taking code that compiled for ARMv4 and recompiling for newer versions, based on some toolchain changes.
<persia> And I don't think I've seen anyone talk about using STM chips, although that doesn't mean nobody does.
<persia> Depending on whether that was one of your more specific questions, or one of your less specific questions, it may be worth asking others, and hoping someone gets back to you about the first.
<persia> But if that was one of your more general questions, you may find faster/better answers somewhere else (although I'd be happy to be proved wrong about that)
<koczis> that was less specific  - cause in fact: 1. I didn't find a word about it in STM32 doc, 2. I have own experience with early/late clear behavior on other arch, 3. I tested it and it looks the late clearing has flaws that make it outcomes unpredictable
<koczis> ...so I use only early clearing now
<koczis> so the more specific question about same thing - how do you do it?
<asac> lool:  * Bug:488267: ffmpeg: "should be built with -marm for lucid on armel"
<asac> cant we just upload that?
<asac> or is there more?
<asac> bug 488267
<ubot4> Launchpad bug 488267 in ffmpeg "ffmpeg should be built with -marm for lucid on armel" [Low,Fix committed] https://launchpad.net/bugs/488267
<asac> bug 456659
<ubot4> Launchpad bug 456659 in linux-fsl-imx51 "suspend/resume failure on imx51" [High,Confirmed] https://launchpad.net/bugs/456659
<asac> plars: isnt that fixed in latest kernel?
<asac> cooloney: ?
<asac> is that still "fix available" ... or should we move that back to "needs investigation" ?
<asac> dmart: hi
<dmart> Hi there
<plars> asac: still fix available, I've been told that they have a fix for it, but I have not heard that it has gone in yet
<asac> dmart: we have  * Bug:458537: linux-fsl-imx51: hibernate does not work
<cooloney> asac: i prepared some kernel deb to do some test,
<asac> someone said, that this bug doesnt make sense for arm
<asac> is that a hardware restriction? or was that just none-sense
<asac> cooloney: can you get plars that deb for verification? or post the url on the bug?
 * asac sets the bug back to in progress
<dmart> (Bug #458537)
<ubot4> Launchpad bug 458537 in linux-fsl-imx51 "hibernate does not work" [High,Triaged] https://launchpad.net/bugs/458537
<cooloney> asac: ok, cool, will update the status of the bug
<dmart> Why doesn't the bog make sense for arm?
<dmart> bug
<lool> asac: 15:55 < lool> asac: The changes are ready in git since Wed; I've tried to  confirm twice with sirestart how he want to handle some other  intrusive changes which are in git (symbol versioning); once  that's clear I can prepare the upload from git
<plars> cooloney: got it, will test shortly
<cooloney> plars: thanks a lot. frankly, i am not sure whether this will fix the issue.
<cooloney> plars: but i will dig into it after i return to Shanghai since my board is there
<plars> cooloney: installing now, should be able to let you know shortly
<cooloney> plars: great, so what is the symptom on your side of that suspend/resume issue
<plars> cooloney: does this kernel also have things to possibly help with the suspend/resume?
<cooloney> plars: yeah, might be, because i merged some patches from FSL latest BSP
<plars> cooloney: on imx51, it seems to suspend (although I have some doubts as to whether it suspends completely), but will not resume
<cooloney> plars: those patches are relatedt to suspend/resume
<plars> if I connect to serial, I can see a message like "<PWR> key pressed" when I push the power button, but nothing happens
<plars> cooloney: oh, you posted it on the hibernate bug
<cooloney> plars: right, i posted both of them, since i applied 30+ patches from FSL latest BSP
<plars> cooloney: will do
<cooloney> plars: need your help to test, because I am traveling now. heh
<cooloney> plars: thx a lot
<plars> cooloney: It's what I do :)  Feel free to point me to stuff like that anytime
<cooloney> plars: appreciate, oh, do you also have BB3 or just BB2?
<plars> cooloney: I'm testing on bb3 at the moment
<plars> cooloney: I have a 2.5, but it is in the box at the moment
<cooloney> plars: cool, thanks a lot
<plars> cooloney: suspend/resume appears to be unaffected by the new kernel, still broken
<cooloney> plars: ok, got you,
<cooloney> plars: i plan to ping fsl guys for help know
<cooloney> plars: if we wanna to resume the suspended board, we press keyboard or the PWR key
<asac> bug 505772
<ubot4> Launchpad bug 505772 in linux-mvl-dove "system freezes sometimes after X is up for a while" [Critical,Confirmed] https://launchpad.net/bugs/505772
<plars> cooloney: neither keyboard, nor power key seem to work.  Also, hibernate still seems to not be supported (not listed in /sys/power/state)
<cooloney> plars: ok, thanks, will ping fsl guys soon
<plars> asac: that one could be related to 504880, definitely still broken
<plars> bug #504880
<ubot4> Launchpad bug 504880 in linux-mvl-dove "[dove] possibility of thumb2 instructions invalidly being handled" [High,Confirmed] https://launchpad.net/bugs/504880
<plars> cooloney: thanks, I'll update the bugs
<cooloney> asac: yeah, i think ericm might know that freezing bug, right?
<asac> bug 504880
<ubot4> Launchpad bug 504880 in linux-mvl-dove "[dove] possibility of thumb2 instructions invalidly being handled" [High,Confirmed] https://launchpad.net/bugs/504880
<asac> cooloney: yes. sorry. just posting here so i can copy that text to release team meeting report
<asac> cooloney: plars: ogra: JamieBennett: https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid
<asac> please check if you want something to get added to summary
<asac> and if i missed anything on the RC bug front
<ogra> asac, uboot NIC issues ?
<asac> ogra: bug?
<plars> bug #507887
<ubot4> Launchpad bug 507887 in uboot-imx "NIC not properly initialized in uboot code" [High,New] https://launchpad.net/bugs/507887
<ogra> https://bugs.launchpad.net/ubuntu/+source/uboot-imx/+bug/507887
<asac> give me id .. .ensure its targetted for lucid and milestoned
<ubot4> Launchpad bug 507887 in uboot-imx "NIC not properly initialized in uboot code" [High,New]
<plars> ha! I win :)
<ogra> heh :)
<asac> "better, strong faster ..." ;)
<asac> plars: ogra: please remember to target such things for lucid ...
<asac> done
<ogra> oh, sorry, i milestoned it for A3 though
<asac> yes, both is required
<asac> also all that are targetted need to be milestoned (i failed in the past)
<asac> and have an assignee
 * asac checks bug list again to see if anything is missing
<plars> asac: 462798 needs a target also, but is medium and I don't know when/if NCommander plans to work on.  NCommander is a3 reasonable for this?
<NCommander> bug #462798
<ubot4> Launchpad bug 462798 in ubiquity "selecting 'new partition table' confuses the partitioning" [Medium,Triaged] https://launchpad.net/bugs/462798
<plars> sorry, asac, NCommander bug #462798
<NCommander> plars, medium, alpha 3, I'm going to work with persia on this during the sprint if we can fix the dove issues
<plars> great!
<plars> will target
<persia> Is that when we're doing it?  I've been wondering :)
<asac> ogra: i will put that uboot net bug on your plate for now ...
<asac> i will also try to help at least to verify
<asac> but i need an assignee
<asac> ;)
<ogra> hrm, k
<asac> ogra: feel free to reassign to someone else from the team ;)
<ogra> heh
<asac> ogra: bug 506761
<ubot4> Launchpad bug 506761 in uboot-imx "lucid uboot hangs on fatload uImage on fsl TO2 TO2.5 and TO3" [Undecided,Confirmed] https://launchpad.net/bugs/506761
<asac> isnt RC anymore
<asac> or should we even close?
<ogra> no, there is still something wonky
<ogra> ext2load works flawless
<ogra> while fatload doesnt
<asac> right. but its not RC
<asac> as we managed to work around
<asac> or is the script loading bug also gone on ext2
<asac> ?
<plars> too bad we don't have something for the "fixed this week" category.  dmucs ftbfs was fixed iirc, but not exactly rc
<asac> right
<asac> well
<asac> lool: i dont understand what i means if you say that ffmpeg is committed to git
<asac> when does that come down to us?
<asac> can we just upload it to ubuntu ?
<ogra> asac, the script *only* loads on ext2
<asac> ;)
<asac> ogra: yeah. ok
<ogra> i cant make it load on fat at all
<ogra> BBG U-Boot > fatload mmc 0:2 0x90800000 boot.scr
<ogra> reading boot.scr
<ogra> ... hangs forever ...
<asac> yeah
<ogra> BBG U-Boot > ext2load mmc 0:2 0x90800000 boot.scr
<ogra> Loading file "boot.scr" from mmc device 0:2 (xxa2)
<ogra> 407 bytes read
<ogra> BBG U-Boot >
<asac> i will check fat code
<ogra> works flawless
<asac> we need to add debugging
<asac> u-boot really needs better debugging facilities imo
<asac> even the DEBUG flags are all broken
<asac> ogra: i can reproduce it, so i can try to work on that if we cant go for ext2
<ogra> well, i wouldnt be surprised if thats due to some vendor patches
<ogra> we cant
<ogra> ext2 needs root
<ogra> we dont have root on the build machine
<asac> sure
<asac> i will check that
<asac> thought e2progs work ... or does that need root too?
<ogra> its to slow
<ogra> NCommander tested it and said its unusable
<asac> err e2tools
<asac> ok. noted
<NCommander> ogra, well, I never looked at optimizing it to reduce the number of e2tools calls
<ogra> NCommander, but you said it takes hours to copy the files
<ogra> even if you optimize that will be to slow
<NCommander> ogra, no, it was about ~10-15 minutes per image
<asac> sounds not that much
<ogra> vs 1-2 min :)
<ogra> thats a lot
<asac> right. but its by far not a dramatic problem
<asac> or how many image runs are we doing?
<asac> one-per-image ... right?
<asac> aka 2 ;)
<asac> rather 4 (with alternates)
<ogra> dont forget a live build already takes 90min
<ogra> during alpha and release time thats already to much
<ogra> (which is why we're still waiting for a second livefs builder to not have to deal with 3h buildtime)
<asac> still. its acceptable imo
<asac> at least as a backup
<asac> i will try to fix fat and talk to uboot folks that did the fsl patches
<asac> its really annoying how fat behaves ;)
<ogra> you mean to fsl folks that did the uboot patches :)
<asac> yes
<asac> i will escalate that if i dont find the issue quickly
<ogra> yeah
<asac> ogra: so you already tried vfat?
<asac> that felt like a good pointer
<ogra> yes, but its already enabled in some common.h file
<ogra> didnt change a thing, just spilled redefine wanrings
<persia> The other massive benefit to FAT is that if we get it working, and get USB support working, we can do bootable USB flash solutions without requiring users to reformat their flash.
<persia> (or FAT-on-SD, with the same benefits)
<persia> Which means no needing to use dd (or wrappers).
<cooloney> asac: just got email from fsl guys, they do not support hibernate, are we going to do that?
<asac> cooloney: if they dont support it, we wont do it ... will remove it from RC bug list after meeting
<cooloney> asac: got it, i think you are in the email loop i sent, let me update the status of the bug hibernate
<asac> thanks
<asac> cooloney: do you know if its a hardware limitation thing? or just because there is no code yet? (or is that in the mail i havent read yet)?
<cooloney> asac: i just checked code quickly, i think there is no code for hibernate.
<asac> ok. but doesnt that need hardware support too?
<asac> ogra: can you link the uboot bug to the spec?
<asac> thx
<asac> slangasek will otherwise poke i guess
<ogra> asac, both ?
<ogra> (NIC and FAT)
<asac> both
<cooloney> asac: and from my experience, it seems no arm soc supports hibernate
<ogra> donr
<ogra> e
<ogra> fun
<ogra> now i can load boot.scr but uimage hangs
<asac> cooloney: right
<asac> thanks
<asac> ogra: make the partition even bigger ;)
<asac> or bad the file with zeros
<ogra> nah, thats cant be it :P
<asac> so its at least a full block :)
<asac> who knows
<asac> i saw code in uboot that said: "always full in full blocks"
<asac> pull
<ogra> boot.scr is 315 byte big and loads fine
<ogra> doesnt load uinitrd either
<lool> asac: You pinged me on this bug
<lool> asac: 15:46 < asac> lool:  * Bug:488267: ffmpeg: "should be built with -marm for  lucid on armel"
<lool> asac: I'm saying that I fixed this and it's pending upload; it's commited in the packaging git repo
<asac> sure
<asac> i understood that. just wasnt sure what that means
<asac> but nevermind
<lool> I dont understand where the ambiguity is
<asac> e.g. is that git repo for debian
<asac> will we wait until it migrates to testing
<asac> etc.
<lool> asac: It's a git repo for debian and ubuntu
<lool> The changes aren't uploaded to Debian
<lool> It's like regular Vcs-Git stuff; not sure what to say
<asac> sure. git just felt like debian
<asac> thats why i double check
<ogra> debian isnt *that* bad, come on
<lool> What's in Vcs-Git for ffmpeg and -extra is correct
<lool> No way to encode the branch infor,mation though
<asac> i dont mind debian, just the time delay if we go through debian first
<asac> thats why i wanted to clarify it
<asac> so all fine ;)
<lool> suihkulokki: You might be interested in kees patch for the ld-linux segfaults
<lool> http://bugs.launchpad.net/bugs/452175
<ubot4> Launchpad bug 452175 in linux "Random segfaults when using ld.so explicitly to start a program" [Medium,In progress]
#ubuntu-arm 2010-01-17
<fta> asac, did you fix the patch?
<fta> asac, ..apparently not :(
<fta> -        ['target_arch=="arm" and _toolset=="host"', {
<fta> +        ['target_arch=="arm" and host_arch=="x64" and _toolset=="host"', {
<fta>            'cflags': ['-m32'],
<fta> asac, ^^
<fta> asac, i can't test so let me know if it's good enough for you or if you still need to drop -m32 unconditionally
<gregoiregentil> I'm trying to port a patch to mplayer on ubuntu/beagleboard, which includes this piece of assembly: http://git.alwaysinnovating.com/cgit.cgi/ai.openembedded.dev/tree/recipes/mplayer/files/yuv.S
<gregoiregentil> the instruction dmb is not recognized when I compile while it's working on my OE build (armv7a)
<gregoiregentil> can I replace the assembly dmb instruction by something else? Or what else needs to be changed to make it work?
<ADcomp> hello
<ADcomp> some help to get my touchscreen working with karmic  ?
<ADcomp> hardware : ADS7846 Touchscreen .. work fine under Angstrom , but not under karmic  ( same kernel/modules/firmware )
<ADcomp> ok .. I think I found the problem ..
<ADcomp> on Angstrom , HAL says : input.x11_driver = 'tslib'  (string)
<ADcomp> and Xorg : (II) config/hal: Adding input device ADS7846 Touchscreen (II) LoadModule: "tslib"
<ADcomp> but with karmic , HAL says : input.x11_driver = 'synaptics'  (string)
<ADcomp> and Xorg : (II) Synaptics touchpad driver version 1.1.2 (**) Option "Device" "/dev/input/event1" (--) ADS7846 Touchscreen: no supported touchpad found
<ADcomp> now how can I change this ..?
<ADcomp> no one ?  :(
#ubuntu-arm 2011-01-10
<rlameiro> rcn-ee: hi are you there?
<rlameiro> rcn-ee: I just got this error using the media creator http://pastebin.ubuntu.com/552331/
<rlameiro> rcn-ee: nevermind, I didnt had linaro-hwpack-install in /usr/bin
<sveinse> Hi. Are there any plans on releasing an gdb-arm-linux-gnueabi for x86/amd64?
<sveinse> It would be nice to have for remote gdb debugging
<sveinse> hrw: Are there any plans on releasing an gdb-arm-linux-gnueabi for x86/amd64?
<smplman> can someone help me get sgx drivers going on my beagleboard xm?
<smplman> i tried libegl1-sgx-omap3 libgles1-sgx-omap3 libgles2-sgx-omap3 with no luck
<rsalveti> smplman: what kind of issues did you have?
<rsalveti> smplman: https://wiki.ubuntu.com/ARM/OMAP/Graphics should be enough to get you a working sgx driver
<rsalveti> cooloney: bug 690370
<ubot2> Launchpad bug 690370 in linux-ti-omap4 (Ubuntu) "Strange out of memory on pandaboard (affects: 2) (heat: 18)" [Undecided,New] https://launchpad.net/bugs/690370
<rsalveti> cooloney: we need to find a way to properly reproduce these issues with upstream and mail it to l-o
<rsalveti> helping debugging and etc
<rsalveti> trying to get more attention from TI on this
<cooloney> rsalveti: yeah, got it.
<Zotan> Has anyone tried using http://42.pl/u/2u8U to rebuild the ubuntu omap kernel for a Beagle?
<cooloney> rsalveti: http://pastebin.ubuntu.com/552603/
<cooloney> rsalveti: http://pastebin.ubuntu.com/552608/
<cooloney> it is arch/arm/configs/omap2plus_defconfig of mainline v2.6.37
<rsalveti> cooloney: cool, still updating my tree
<elesueur> rsalveti: do you know much about the cpuidle implementation for panda?
<rsalveti> elesueur: not much in details, but exactly do you want to know?
<elesueur> there seem to be some strange restrictions on when cores can go into deeper sleep states
<elesueur> according to a guy at TI, cpu0 can only go into deep sleep when cpu1 is offlined with the hotplug architecture...
<elesueur> which i've confirmed is the way it's working at the moment
<hrw> I wonder when omap4 will get used in any mobile device...
<rsalveti> elesueur: oh, ok, probably can't help you much here
<rsalveti> unfortunately
<armin76> hrw: does the playbook count?
<hrw> armin76: RIM playbook?
<armin76> hrw: yes
<hrw> good for start
<armin76> i read somewhere it had an omap4
<tmzt> how did the ac100 experiements fgo?
<tmzt> go
<hrw> Texas Instruments and RIM have confirmed that the application processor inside the upcoming Blackberry PlayBook tablet is the dual-core OMAP 4430.
<hrw> found on web
<hrw> good
<tmzt> which leaves the baseband choice wide open, interesting
#ubuntu-arm 2011-01-11
<ogra> GrueMaster, bug 532733
<ubot2> Launchpad bug 532733 in qemu-kvm (Ubuntu Lucid) (and 2 other projects) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 10) (dups: 1) (heat: 81)" [High,Incomplete] https://launchpad.net/bugs/532733
<ogra> err
<ogra> wrong one
<ogra> GrueMaster, bug 674146
<ubot2> Launchpad bug 674146 in gcc-4.5 (Ubuntu Natty) (and 6 other projects) "dpkg segfaults during debootstrap on natty armel (affects: 1) (heat: 76)" [High,Fix released] https://launchpad.net/bugs/674146
<Homefix> Hello
<Homefix> I have a question anyone with a sec
<Homefix> I have, im sure to most of you fine folks, is a simple question concerning rootfromscratch would i be wasing my time just to post it ?
<rcn-ee> one must ask to find out...
<Homefix> cool
<Homefix> Iim wasting my time setting up ubuntu on my evo and epic phones
<Homefix> I* have succ setup the premade image and my own image using the edubuntu website,
<rcn-ee> there's really no ubuntu 'kernel' for that situation, the most you'd get is a ubuntu userspace you could chroot into..
<Homefix> hold on now i type slow
<Homefix> I am happy with what i have done with this i am running programs on my phone with maveric lucid and jaunty
<Homefix> however
<Homefix> my question is
<Homefix> when i use the premade image everything is a oty
<Homefix> when i chroot with my built image,
<Homefix> i get hold on i have to cut and paste this
<Homefix> Can not write log, openpty() failed (/dev/pts not mounted?)
<Homefix> and termanil does not work
<Homefix> on my phone
<Homefix> not in qemu
<Homefix> is that make sense
<Homefix> ?
<rcn-ee> so... a premade image works.. your built image doesn't work.... question? who made the 'premade' image..
<Homefix> its the one here.....
<Homefix> https://wiki.ubuntu.com/ARM/RootfsFromScratch
<Homefix> the ubuntu terninal does not have a prompt in ubuntu on my phone
<Homefix> in the premade one it works
<Homefix> i have been doing this for days and days
<Homefix> i wrote this hold on and ill link it
<Homefix> http://forum.xda-developers.com/showthread.php?t=881401
<Homefix> i dont under stand the premade was supposivly made using "the steps above"
<Homefix> in the article that is
<rcn-ee> ah, so it's more then just the premade image..   is this the one that works? http://w3.impa.br/~gabrield/data/ubuntu-arm-development-rootfs.tar.bz2
<Homefix> 1 sec
<Homefix> yes
<Homefix> that was not made with the steps above in the article?
<rcn-ee> well, that's not an ubuntu.com download, more then likely the user who uploaded it did something else special, you should ping him..
<Homefix> ping him?
<rcn-ee> well, if you work your way down his web link: http://w3.impa.br/~gabrield/ looks like a homepage with contact info..
<Homefix> thanks
<Homefix> so for sure you think he modified it some how
<rcn-ee> nope.. i have no idea if he modified anything.. but to ask him how he built it would be the next logical step..
<Homefix> cool thans for the help (one of the links pointed here)
<rcn-ee> Homefix, another thing, that premade was karmic, with lucid+ you need CONFIG_DEVTMPFS which maybe causing the /dev/pts issue too..
<Homefix> I tried every poss conception :(
<Homefix> I even made jaunty could not get it to chroot
<Homefix> i wrote to rsalveti maybe ill have luck
<Homefix> Query is the way to message someone? im new to irc
<Homefix> the premade is great however there is only 2G 3 much better
<Homefix> Of coarse that was meant as -image 2G not 2g coverage ;)
<Homefix> rcn-ee: by the way is this, CONFIG_DEVTMPFT somthing i can just throw in there
<rcn-ee> no it's a userspace/kernel requirement of lucid... so IF you where able to make a working karmic image, but only LUCID/MAVERICK failed, that would be one thing to look into..
<Homefix> no mav does the same thing
<Homefix> ill just have to hope auther gets back
<rcn-ee> well he's probally still asleep, about 80-90% of the developers on this list are in europe...
<Homefix> awww lern smtng new each day
<Homefix> i new what ping was by the way, i thought irc had some strange contact method or somthing haha
<Homefix> now that i think about it i used the prebuilt image and do-release-upgrade to maveric and terminals worked fine just need bigger image 3G
<sveinse> Anyone doing remote gdb debugging for armel/omap target?
<Homefix1> Hi i was hoping you could help me with this problem:
<Homefix1> I am using (on a dedicated ubuntu computer with Maverick edition)"https://wiki.ubuntu.com/ARM/RootfsFromScratch" example to create a qemu image using "sudo rootstock --fqdn ubuntu --login ubuntu --password ubuntu --seed nano --notarball --imagesize 3G".
<Homefix1> I have also used the "sudo project-rootstock/rootstock --fqdn ubuntu --login ubuntu --password ubuntu --seed nano --notarball --imagesize 3G"
<Homefix1> and: "sudo ./rootstock --fqdn ubuntu --login ubuntu --password ubuntu --seed nano --notarball --imagesize 3G" way.
<Homefix1> They all work great. I am able to load the image with qemu, got ssh setup and working alls great in life.
<Homefix1> The problem lies HERE:(.......
<Homefix1> I am using these images (mostly for fun), to setup ubuntu onto my Evo and Epic smartphones using this method: "http://forum.xda-developers.com/showthread.php?t=881401" to chroot the image.
<Homefix1> ITS AWSOME IT WORKS AND LOTS OF FUN!
<Homefix1> well sorry for screaming but it really excites me this open source Ubuntu Stuff. (i am a win user, but I found a new toy)
<Homefix1> Using the prebuilt image everything works excellent (except for the small image size 2G) that is why i need to use my 3G built image.
<Homefix1> My problem: My built image works flawlessly as well, with one exception, (that i have noticed) is, inside ubuntu (on my phone chrooted with android) the terminals do not have a prompt# only black, square curser, and will not except input. I have to use the terminal program inside android to apt-get and such.
<Homefix1> I have noticed with my build images, using apt-get during install, i see "Can not write log, openpty() failed (/dev/pts not mounted?)"
<Homefix1> error. My reserch says terminals wont work if system cannot write to /dev/pts.
<Homefix1> The prebuilt image does not have this issue.
<Martyn> Morning
<Martyn> Has anyone here written network device drivers?
<Martyn> I'
<Martyn> I'm torn between using alloc_skb and netdev_alloc_skb
<Martyn> (or now that I've found it, netdev_alloc_skb_ip_align() )
<Homefix1> hello anyone listening i culd use some help with an ARM question?
<topfs2> just ask
<Homefix1> Ok
<hrw> Homefix1: do not ask to ask but ask - gold rule of irc
<Homefix1> Hi i was hoping you could help me with this problem:
<Homefix1> I am using (on a dedicated ubuntu computer with Maverick edition)"https://wiki.ubuntu.com/ARM/RootfsFromScratch" example to create a qemu image using "sudo rootstock --fqdn ubuntu --login ubuntu --password ubuntu --seed nano --notarball --imagesize 3G".
<Homefix1> I have also used the "sudo project-rootstock/rootstock --fqdn ubuntu --login ubuntu --password ubuntu --seed nano --notarball --imagesize 3G"
<Homefix1> and: "sudo ./rootstock --fqdn ubuntu --login ubuntu --password ubuntu --seed nano --notarball --imagesize 3G" way.
<Homefix1> They all work great. I am able to load the image with qemu, got ssh setup and working alls great in life.
<Homefix1> The problem lies HERE:(.......
<Homefix1> I am using these images (mostly for fun), to setup ubuntu onto my Evo and Epic smartphones using this method: "http://forum.xda-developers.com/showthread.php?t=881401" to chroot the image.
<Homefix1> ITS AWSOME IT WORKS AND LOTS OF FUN!
<Homefix1> well sorry for screaming but it really excites me this open source Ubuntu Stuff. (i am a win user, but I found a new toy)
<Homefix1> Using the prebuilt image everything works excellent (except for the small image size 2G) that is why i need to use my 3G built image.
<Homefix1> My problem: My built image works flawlessly as well, with one exception, (that i have noticed) is, inside ubuntu (on my phone chrooted with android) the terminals do not have a prompt# only black, square curser, and will not except input. I have to use the terminal program inside android to apt-get and such.
<Homefix1> I have noticed with my build images, using apt-get during install, i see "Can not write log, openpty() failed (/dev/pts not mounted?)"
<Homefix1> error. My reserch says terminals wont work if system cannot write to /dev/pts.
<Homefix1> The prebuilt image does not have this issue.
<hrw> so mount it?
<Homefix1> hrw: who are you talking to
<Homefix1> when i try to mount /dev/pts I get "devpts already mounted or /dev/pts busy mount: according to mtab, devpts is already mounted on dev/pts
<hrw> mounted it also inside of chroot?
<Homefix1> the chroot scrips remain unchanged prebuilt "image" works however My "image" does not it lies within image no?
<hrw> I do mount of /dev/pts /proc inside of chroot always
<Homefix1> could you take a look at #modprobe ext2
<Homefix1> Here:http://forum.xda-developers.com/showthread.php?t=881401
<Homefix1> I leave the script unchanged between images one is able to write to dev/pts other image does not same karmic build
<Homefix> hur sorry lost my conn.
<Homefix> Im back
<Homefix> hrw: im back
<Homefix> I have to reboot be back in 3min
<Homefix1> hrw: sory are you with me?
<Homefix1> I have this question anyone have some time to look? Scroll to my last post http://forum.xda-developers.com/showthread.php?p=10516800#post10516800
<ogra> GrueMaster_, nilfs2-tools
<ogra> GrueMaster_, http://www.nilfs.org/
<Homefix1>  ogra: what is the differance between this "gabrield/data/ubuntu-arm-development-rootfs.tar.bz2" and "this "rootstock --fqdn ubuntu --login ubuntu --password ubuntu --dist karmic --notarball --imagesize 3G" I am having issues with my terminal and getting this error Can not write log, openpty() failed (/dev/pts not mounted?) do ya have a minute to look at this "http://forum.xda-developers.
<Homefix1> com/showthread.php?t=881401" (scroll to the bottom)
<Homefix1> Thanks
<ogra> Homefix1, i have no idea, i guess you would have to ask gabrield (whoever that is)
<Homefix1> ogra: no no this "http://w3.impa.br/~gabrield/data/ubuntu-arm-development-rootfs.tar.bz2, is the prebuilt image offered here https://wiki.ubuntu.com/ARM/RootfsFromScratch you dont know who made it? I only ask because you are the contact under article.
<ogra> i dont know either, its not made by any ubuntu person
<ogra> find out who that gabrield guy is and talk to him
<Homefix> ogra: Im sorry i lost my connection could you repeat your answer if you did?
<ogra> i dont know either what that image is, its not made by any ubuntu person
<ogra> find out who that gabrield guy is and talk to him
<Homefix> ogra: if you dont mind how do you fit in or what do you have do do your role with the article "https://wiki.ubuntu.com/ARM/RootfsFromScratch"
<ogra> i wrote rootstock initially and i initially created that wikipage (two years ago)
<Homefix> i guess what im trying to ask is where did the image come from'
<ogra> i didnt touch either of it since a year, rsalveti maintains the code now
<ogra> but none of us has anything to do with the changes of the wikipage
<ogra> according to the url you pasted above the image came from some brazilian guy named gabrield
<ogra> (but thats something you can guess yourself by looking at it)
<Homefix> ogra: were you able to read my long question i emailed to you i really would like to fix the "Can not write log, openpty() failed (/dev/pts not mounted?)" thing it really has nothing to do with gabriel anyway
<ogra> no, thats likely your kernel missing bits
<ogra> either devtmpfs or udev usually create this device
<ogra> if your kernel lacks devtmpfs udev should care, make sure it is running ...
<Homefix> kernel in image or in my android device i use the image with
<Homefix> ogra: it doesnt make sense if my device is lacking bits it would not work for either image .Both karmic and if the image was modified in what direction should i look to find how to modify myself
<ogra> compare /dev
<Homefix> by the way i ment kernel on development machine not in the image
<ogra> there surely is no kernel in the image
<Homefix> corse not
<Homefix> ogra: forgive me for being a newb can u tell me do you mean to compare /dev folders between images?
<ogra> look at the contents
<ogra> (of the /dev folders)
<mwhudson> hello
<mwhudson> can someone tell me anything interesting about the yaffs2 file system?
<mwhudson> in particular what i have to do to be able to mount yaffs2 images on my laptop...
<Homefix> ogra: i am using my chrooted with my built image using android terminal logged in typed cd /dev then ls got a lot of stuff
<ogra> inside the chroot ?
<Homefix> yes
<Homefix> i have a ubuntu prompt
<ogra> well, compare with the image
<ogra> and see what the difference is
<Homefix> root@localhost:/dev# is it actually
<Homefix> and of corse you mean to run qemu gabriels image and look for differances?
<Homefix> I hope
<ogra> lool, could we have a chat about bug 623375 while we have face to face abilities ? it just hits us here
<ubot2> Launchpad bug 623375 in initramfs-tools (Ubuntu) "Skipping the bootloader installation when creating rootfs or installation media (affects: 1) (heat: 27)" [Undecided,New] https://launchpad.net/bugs/623375
<ogra> Homefix, really, just compare the directory content of both /dev directories, if there is anything lacking in one, use MKDEV to create the device files
<ogra> err
<ogra> MAKEDEV
<Homefix> You the person thnks
<lool> ogra: Ok
<lool> ogra: I'm in Lonestar III
<ogra> ok, heading upstairs in 5
<GrueMaster> ogra: https://wiki.ubuntu.com/MobileTeam/BugWorkflow
<rsalveti> lol
<Homefix> When i do MAKEDEV update i get "eval: 1: major_device-mapper=254: not found" the curser looks like its awaiting input or is it doing somthing its been a few minuts
<ogra> did you read the manpage ?
<Homefix> no Im a noob thnx
<Homefix> Hi oqra there seems to be quite a bit missing in the dev folder between the two images however i have no clue how to put these device files back such as tty38 i know its a terminal device file or whatever but how do i get it from one image to the other
#ubuntu-arm 2011-01-12
<Homefix> ogra: Thank you I now have a #
<SaidKLE> Alright, I just rooted my haipad m701 and I'm dieing to see if I can install ubuntu on it.
<SaidKLE> Totally new to this, and there isn't much by way of how-to's online.
<may_null> Hey I'm following steps here -> http://elinux.org/BeagleBoardUbuntu#Maverick_10.10_2.. But when I boot and see xfce graphical display generally it's not recognize my usb mouse or keyboard
<may_null> Do I missing some packages or ?
<ian_brasil> ogra: did you get a chance to look at why the kubuntu mobile image is not building ok?
<ian_brasil> gabrield is Gabriel Duarte http://w3.impa.br/~gabrield/
<rsalveti> GrueMaster: don't know if you noticed, but this new image is already using the latest u-boot that jcrigby updated
<rsalveti> and it seems fine, so that's good :-)
<jcrigby> woohoo!
<GrueMaster> Hadn't noticed (serial issues), but great news.
<GrueMaster> ogra: The error I am getting is "Error showing url:  The specifiedlocation is not supported".  I can reproduce it on the cmdline.
<ogra> GrueMaster, thx
<rsalveti> jcrigby: did the sd card work properly for you?
<jcrigby> yes, thanks so much.  All the panda boards worked
<rsalveti> jcrigby: awesome!
<ogra> NCommander, "Handle modification of jasper-initramfs to use userspace archdetect" from other-arm-n-userland-subarch-detection .... what am i supposed to do with that ? the output of archdetect isnt useful at all to jasper anywhere
<NCommander> ogra: if subarch detection isn't userful to jasper, nuke the item
<ogra> k
<ogra> NCommander, jasper needs to know the actual board it runs on, archdetect only spits out the arch
<ogra> (because we install different bits for different boards of the same arch)
 * ogra nukes
<NCommander> ogra: *groan*, yeah, thats annoying and so shouldn't be necessary but it is :-/
<ogra> persia, /usr/bin/devicetype-detect: 123: /bin/true): not found
<ogra> persia, fix at http://paste.ubuntu.com/553395/
#ubuntu-arm 2011-01-13
<loltoad> so i have a USB interface to this lm3s8962 board, and it creates a /dev/ttyUSB0, how do i flash it?
<hrw> morning
<rsalveti> vstehle: https://wiki.linaro.org/WorkingGroups/KernelConsolidation/Projects/FlashCardSurvey
<velory> Hi, I'm using ubuntu on arm with xfce DE.. Is there any interface that I can connect wireless or should I connect from terminal ?
<rsalveti> velory: nm-applet?
<velory> rsalveti:  I don't know nm-applet , downloaded wcid right now but it says it couldn't open wicd D-Bus interface
<janimo> velory, nm-applet is network manager, you could try that
<rsalveti> GrueMaster: fun for you: bug 688765
<ubot2> Launchpad bug 688765 in linux (Ubuntu Maverick) (and 1 other project) "Can't init uart3 (no clocks available) at Beagleboard-xM (affects: 1) (heat: 12)" [High,Fix committed] https://launchpad.net/bugs/688765
<mwhudson> rsalveti: ping
<mwhudson> rsalveti: i have a panda here and i would like to boot it
<mwhudson> i hear you have an image that works?
<GrueMaster> mwhudson: http://cdimage.conference/ubuntu-netbook/daily-preinstalled/20110112/
<GrueMaster> That is our daily preinstalled image.
<mwhudson> GrueMaster: thanks
<GrueMaster> Last night's image failed to build due to a dependency (happens).
<GrueMaster> You will need a monitor, keyboard, and mouse.
<mwhudson> ah
<mwhudson> there's no headless?
<GrueMaster> It is a netbook image.  We have a blueprint to create a minimal image, but it is WIP.
<GrueMaster> You can also roll your own with rootstock.
<GrueMaster> https://wiki.ubuntu.com/ARM/RootStock
<GrueMaster> mwhudson:  ^^^
<mwhudson> i'll try the linaro headless i guess
<rsalveti> mwhudson: pong
<rsalveti> mwhudson: try linaro headless, otherwise we can easily generate a minimal image for you
<mwhudson> rsalveti: nm, GrueMaster helped me out
<mwhudson> rsalveti: that would be really nice actually
<rsalveti> mwhudson: ok, give me a minute
<mwhudson> (having a battle getting the linaro stuff to behave)
<ndec> cooloney: hi! i am trying to boot mainline kernel (.37) with maverick minimal FS, and i got a panic right at init. it works with busybox FS. so somehow ubuntu requires some defconfig which might be missing. any idea?
<ndec> rsalveti: sebjan: ^^^ in case you are interested...
<mwhudson> rsalveti: getting anywhere with that image?
<rsalveti> mwhudson: getting a weird qemu bug :-(
<mwhudson> bah
<mwhudson> my day is full of yaks
<rsalveti> mwhudson: http://paste.ubuntu.com/553687/
<mwhudson> rsalveti: oh, i think i had that
<rsalveti> let me try a maverick rootfs
<mwhudson> rsalveti: get the qemu-kvm-extras-static from natty
<mwhudson> rsalveti: http://launchpadlibrarian.net/62064032/qemu-kvm-extras-static_0.13.0%2Bnoroms-0ubuntu11_amd64.deb
<rsalveti> oh, saw the bug
<rsalveti> fixed with latest one
<rsalveti> ok
<rsalveti> trying again
<rsalveti> sorry for taking so long, lots of interruptions around :-)
<rsalveti> ndec: cooloney could boot it with upstream kernel
<rsalveti> let me ping him to send you his .config
<mwhudson> rsalveti: no kidding
<mwhudson> (it also seems my panda doesn't want to boot at all)
<ndec> rsalveti: yes, but with the natty defconfig, not the default config from mainline kernel. maybe i wasn't clear... in fact I am looking for the CONFIG that are needed on top of mainline to make it work
<rsalveti> mwhudson: weird, are you at least getting to x-loader and u-boot?
<mwhudson> rsalveti: no
<mwhudson> i now have jcrigby on the case
<rsalveti> mwhudson: hm, ok
<cooloney> ndec: what i did is
<cooloney> 1) generate the kernel config file in natty ti-omap4
<cooloney> 2) copy that to mainline kernel tree as .config
<cooloney> 3) load that .config when running menuconfig
<cooloney> 4) build the kernel with that .config and the kernel is supposed to be ok on Panda with ubuntu root filesystem
<rsalveti> GrueMaster: can you target bug 694059 for maverick for me? I added the qemu-kvm component but can't target to a specific distro version
<ubot2> Launchpad bug 694059 in qemu-kvm (Ubuntu) (and 1 other project) "qemu fatal cp15 message report and image creation block (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/694059
<GrueMaster> Sure, on it.
<rsalveti> weee qemu: uncaught target signal 6 (Aborted) - core dumped
<rsalveti> mwhudson: ok, finally generated it, will test
<jcrigby> rsalveti, I have that qemu problem.  The version on natty (.13) fixes it.  There is a maverick version in my ppa.
<jcrigby> as a workaround
<rsalveti> jcrigby: yup, but I wanted that to be fixed at the archive
<jcrigby> rsalveti, I understand just letting you know of the binary for workaround
<rsalveti> jcrigby: oh, sure :-)
<rsalveti> thanks
<rsalveti> mwhudson: finally something that works
<rsalveti> mwhudson: http://people.canonical.com/~rsalveti/rootfs/natty/
 * mwhudson sees he's not the only one not eating lunch yet
<mwhudson> rsalveti: how do i use this?
<mwhudson> rsalveti: thanks a lot, btw :)
<rsalveti> mwhudson: the rootfs you just extract to your desired partition (usb, sd card, whatever)
<rsalveti> then for the first partition, it needs to be a fat one, as the linaro script creates
<rsalveti> just copy the boot files over there and it should boot fine
<mwhudson> ah ok
<rsalveti> mwhudson: ok, just updated the boot files again
<rsalveti> http://people.canonical.com/~rsalveti/rootfs/natty/boot/
<rsalveti> with proper cmdline if you want to use X later on with gst and stuff
<rsalveti> and the correct uImage
<rsalveti> just tested and it's working fine on my pand
<rsalveti> if you want, just get to the ARM room and get my sd card
<rsalveti> you can test with it, I'm not using
<rsalveti> user ubuntu/ubuntu
<rsalveti> sakoman_: the new u-boot rocks, booting a lot faster, thanks a lot
<mwhudson> rsalveti: thanks, seems to be booting
<rsalveti> mwhudson: awesome
<mwhudson> (with the old boot files i expect, but that's ok, i don't want to use x)
<rsalveti> mwhudson: ok, should work the same way
<rsalveti> jcrigby: http://gitorious.org/~rsalveti/x-loader/ubuntu-x-loader
<rsalveti> jcrigby: https://launchpad.net/ubuntu/+source/x-loader
<rsalveti> https://launchpad.net/ubuntu/+source/x-loader/1.4.4+git20101223+6f3a261-1ubuntu0/+build/2148178
<cooloney> sebjan: i turned on "Enable L3 error logging" and will test kernel building again.
<cooloney> sebjan: hope i can get some information about the failure
<mwhudson> rsalveti: does /usr/lib/apt/methods/https using 100% cpu for several minutes on a panda sound like a problem?
<ogra> mwhudson, nah, not really :P
<ogra> mwhudson, thats update-apt-xapian-index i would guess
<mwhudson> aah
<mwhudson> ok
<mwhudson> it's progressing now
<ogra> installing htop is a clever move ;)
<cooloney> sebjan: it looks there is no L3 error at all when I got bus error from gcc.
<mwhudson> ogra: can i turn update-apt-xapian-index off?
<ogra> ask mvo
<ogra> i'm n ot sure what it implies if you dont have it running, i guess software center will become very slow when searching in it
<mwhudson> ogra: turns out it's not installed
<ogra> mwhudson, hmm
<ogra> then its probably update-manager itself
<lool> mwhudson: You can divert it to /bin/true  :-)
<mwhudson> lool: heh heh
<mwhudson> sadly i don't think diverting .../apt/transports/https to true would have the desired effect
#ubuntu-arm 2011-01-14
<rlameiro> rcn-ee: ping
<rcn-ee> rlameiro, pong (just walked in)
<rlameiro> rcn-ee: I am getting an erron on the linaro-create-media script
<rlameiro> IIRC you made it, maybe you can help me
<rlameiro> rcn-ee: http://pastebin.ubuntu.com/553827/
<rcn-ee> hey rlameiro, i did the intial implementation, if it's one of the extensions i might not be any help... (loads pastebin)
<rlameiro> rcn-ee: lameiro@studiobeta:~/stagepd/linaro$ linaro-media-create --rootfs ext3 --mmc /dev/mmcblk0 --dev igep                     --binary linaro-m-netbook-efl-tar-20101108-1.tar.gz                     --hwpack hwpack_linaro-igep_20101109-1_armel.tar.gz
<rlameiro> this is the command I ran
<rlameiro> I even bought a diferent sd card... i tought it could be it
<rcn-ee> (finally found src location)
<rlameiro> rcn-ee: lol, sorry...
<rcn-ee> yuck..  it's really nothing like it use to be...
<rcn-ee> i don't think i can help you too much rlameiro, if you consider what i orignall wrote to be a model t.. it's more like a porshe right now.. i'd be pretty useless right now with it..
<rcn-ee> i'd first double check, does it properly recoginze /dev/mmcblk0 have "pX" partition names, vs /dev/sda have "X" anmes..
<rlameiro> rcn-ee: dont know, shouldnt it work with the root disk?
<rlameiro> i can wipe out the disk and leave it blank again. I tried it and it gave me an error
<rlameiro> will try again
<rlameiro> rcn-ee: weird... the script did formatted the card.. it has 2 partitions .... one fat and other ext3.... i think it recognizes it
<rcn-ee> yeah, it looks like it formated fine, but when mounting the first time to populate some data it bombed..
<rlameiro> rcn-ee: yeap
<rlameiro> it doent mount. I took the card out and in again and ubuntu doesnt mount it
<rlameiro> could it be some config problem?
<rcn-ee> i don't think so.... do you have any other card readers?  only my work laptop has the /dev/mmcblk0pX syntax so i can't test anything at the moment..
<rlameiro> rcn-ee: nop. its the builtin. But i am thinking on buying one for some time now. i think tomorrow i will buy one and then see if it is the reader fault
<SaidKLE> Question: are there any how-tos for native install of ubuntu on mids?
<rsalveti> robclark: yep, we have 2 around here
<robclark> rsalveti: cool
<robclark> GrueMaster: https://bugs.launchpad.net/ubuntu/+source/oprofile/+bug/55871
<ubot2> Launchpad bug 55871 in oprofile (Ubuntu) "oprofile doesn't seem to work with VMware (heat: 1)" [Low,Confirmed]
<GrueMaster> robclark: THat was an ancient bug.  Here is a new one:
<GrueMaster> Bug #702999
<ubot2> Launchpad bug 702999 in oprofile (Ubuntu) "oprofile failure on armel (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/702999
<robclark> cool, thx GrueMaster
<armin76> bug 1
<ubot2> Launchpad bug 1 in tilix (and 20 other projects) "Microsoft has a majority market share (affects: 614) (heat: 2979)" [High,New] https://launchpad.net/bugs/1
<armin76> :D
<armin76> robclark: fix
<robclark> armin76: heheh
<rsalveti> robclark: https://launchpad.net/~rsalveti/+archive/qt-neon
<rsalveti> alf: do you remember the package name that had the cdbs class used to do arch specific changes?
<rsalveti> I think it was gdk-pixbuf
<GrueMaster> ogra: I was going over the bug work list, and found that Bug #645659 was fixed prior to maverick release.  I've marked both jasper-initramfs and flash-kernel as fix released.   Correct me if I am wrong.
<ubot2> Launchpad bug 645659 in jasper-initramfs (Ubuntu) (and 1 other project) "flash-kernel doesn't work with the IGEPv2 board (affects: 1) (heat: 12)" [Medium,Fix released] https://launchpad.net/bugs/645659
<ogra> GrueMaster, thanks, i think its fine
<gerflo> hi folks - I successfully  installed and managed to boot ubuntu-netbook-10.10-preinstalled-netbook-armel+omap.img on my IGEPv2 board and now I need the default login/password to access my machin, anyone to help me here ?
<GrueMaster> gerflo: There is no "default" password.  On the second boot, the system should start X and launch oem-config, which will prompt you for language, locale, keyboard, and user settings.
<gerflo> OK -so I have to boot twice - I wil check this - thank you...
<rsalveti> if not then you're not using the initrd
<GrueMaster> First boot resizes the root partition,and it automatically reboots from there.
<gerflo> hm - mine did boot into normal graphical login as I know from several other Ubuntu systems...
<GrueMaster> gerflo: Very odd.  It should beloading both uImage and uInitrd from the first partition.  If it is only loading uImage (kernel), then something is wrong.
<gerflo> OK - second boot finished an now boots into desktop without login prompt  - thank you guys, this was to simple ;-)
<gerflo> now let's try to install XBMC and than hopefully Airplay :-)
<alf> rsalveti: or gtk3?
#ubuntu-arm 2011-01-15
<rsalveti> alf: could be, will check, thanks
<eric1> When I use apt-get install gnome on my Ubuntu Arm I get this error http://mibpaste.com/2O95XF
<RoDuS> can some one help me with a question
<RoDuS> i have an arm11 telechips 9802 mother boarded hsg-x5a android touch pad, the more i use android the less i  like it, is there a tutorial on installing ubuntu-arm on the device, or a multi-boot debian-droid like the smartq touchpad?
<rsalveti> ogra: GrueMaster: cool, at least I now got the image fail log for omap 3!
<rsalveti> we should be able to get an image soon
<bweb> hey, what is the minimum of power consumption of a ARM linux environment? I am searching for Best Available Technologyâ¦
<armin76> bweb: 0W if powered off :D
<bweb> armin76: I am searching for a ultra-low voltage system with less than 1 watt - always on!
<NTU> i think porting Ubuntu to ARM is a complete waste of time, considering its an epically failed distro filled with bugs and unnecessary changes to package names and source code, just to make life more confusing for everybody. Thank you. :)
<mellis> i have a problem with ubuntu on my beagle it was running fine then the power went off to it and now it boots fine but i get nothing on the screen
<td123> anyone know some cheap netbook/smartbook/notebook/tablet with an arm processor that is easily hackable?
<td123> the ac100 requires a bios mod from what I read, and I would like to avoid something like that
<td123> otherwise, I would be getting a shipment next week :)
<mellis> yh maplin sells a really cheap laptop if you cann call it it that
<mellis> or they did lol
<mellis> http://www.maplin.co.uk/ubisurfer-ce-netbook-with-1-year-free-internet-access-394361
<mellis> dont know how hackable it is but stil
<td123> uhh, hw is a little lacking though
<td123> I wouldn't mind paying a little extra for some beefier hardware
<td123> 128mb is pretty restricting for most linux desktops
<Min1123> Hi, I'm attempting to install 10.10 from the netbook preinstall image on my release Pandaboard, and I am being wildly unsuccessful.
<Min1123> It does the initial boot and resizes, then it reboots and the screen never comes up.
<Min1123> So I tried to work around it by inserting an xorg.conf that has fbdev as the driver for X, but then the UUID on the flash card somehow changed.
<Min1123> After that I reworked the boot.scr using mkimage so that it would boot via device, but the Xserver now just crashes until GDM gives up.
<Min1123> Not knowing the username or password for it in the OEM state, I haven't tried logging in.
<Min1123> Any ideas?
<Min1123> On an unreleated note, does anyone know how to get the ARM netboot images to play nice with the Pandaboard?
<niklasfi> hi. i have a beagleboard xM with a coretex A8 processor. i am following https://wiki.ubuntu.com/ARM/OMAPMaverickInstall . do i need an omap3 or the omap4 image?
<loafhead> niklasfi: omap3
<niklasfi> loafhead: thanks
<Amaranth> yay, going through oem setup on my panda
<Amaranth> first boot the keyboard and mouse didn't work, rebooted and they're working now :)
#ubuntu-arm 2011-01-16
<Jack87> anyone play with ubuntu on nook color?
<Jack87> nook color owners around?
<rsalveti> robclark: wasn't able to finish my build at my panda, even after 15 hours hehe
<rsalveti> robclark: I'm now waiting the ppa one to be finished, should be done in more 3, 4 hours
<rsalveti> then will copy to my public ppa and send you the link
<robclark> rsalveti: cool, thx
<velory> Hi I'm using ubuntu-arm on beagle and connected philips tv/monitor with hdmi cable.. I'm getting graphical display but when I look monitors from system preferences it doesn't seem recognized monitor at all just outputing default display.. Is it possible to make it recognized ?
<LBo> velory: what graphics driver are you using?
<LBo> I believe nvidia doesn't support xrandr and therefore cannot be used through the monitors program
<velory> LBo:  well it's beagle Imagination TechnologiesÂ PowerVRÂ SGX 2D/3D graphics processor supporting dual independent display
<armin76> lol
<velory> what ?
<Amaranth> How do you get egl and glesv2 headers on omap4? The only -dev packages I see are the mesa versions and installing those wants to uninstall the pvr drivers
<topfs2> Amaranth: thats the only way to do it atam
<topfs2> you can install the mesa version and copy out the headers and copy in them again manually after you have installed the real drivers (I guess not really recommended)
<Amaranth> hrm, it seems the omap-trunk ppa wants stuff I don't have
<Amaranth> like a kernel that defines DRIVER_USE_PLATFORM_DEVICE
<Amaranth> and the pvr driver in there is missing an include for linux/platform_device.h
<Jack87> do we have nook color porters here?
<Jack87> is there a debootstrap for maverick?
<Jack87> for arm
<Jack87> so quiet :(
#ubuntu-arm 2012-01-09
<RussellAlan> Oui
<RussellAlan> Greetings to those lurking.
<infinity> jcrigby: When do I get my mx53 kernel for amrhf? ;)
<OlivierN1> Sage: the 11.10 image contains bootloaders for Panda. It might work on Blaze, but not guaranteed. Basically you need to rebuild the bootloaders and update the 1st partition inside the image file (unfortunatelly I can't a how-to on this).
<OlivierN1> Sage: in case you have a Panda, you may (1) complete the Ubuntu installation on Panda (2)  install u-boot-linaro-omap4-sdp4430 (3) now use this SD card on Blaze
<OlivierN1> (btw, there is no non-hacky way of detecting Blaze/Panda at run-time in the bootloaders)
<ogra_> ndec, not sure if you noticed already, your PPAs are armhf enabled now ;)
<Sage> OlivierN1: any url for blaze vs panda bootloader differences?
<OlivierN1> Sage: don't know. Though many peripherals are different
<OlivierN1> Save: btw, I forgot step 2.5: sudo flash-kernel --update-bootloader
<Sage> The main thing what I'm missing is what patches does blaze need to get the display working on upstream kernel. I have build Mer image for pandaboard and same image boots on blaze but I have problems with the display, thus wondering what I'm missing and wanted to try ubuntu if thing work better there.
<OlivierN1> since the pin muxing is different on Blaze and Panda, the 1st thing is to get the right bootloaders
<OlivierN1> then the following kernel have support for Blaze LCD:
<OlivierN1> http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=shortlog;h=17cf2a338dab866f59837ec8a7701878c7d38ca3
<OlivierN1> Sage: ^
<Sage> OlivierN1: ok, thx. I can try with that kernel then. What I would need next is x-loader and u-boot modifications if there is difference needed between blaze and panda.
<janimo> rsalveti, is there a linaro uboot tree that has bot omap4 and omap3 spl in it?
<Sage> OlivierN1: or if changing the kernel cmdline is enough for boot process?
<Sage> OlivierN1: so it is the omap4_defconfig that contains also blaze support?
<OlivierN1> Sage: yes, there are different sets of bootloaders but a sole kernel for both
<OlivierN1> (and I don't know how much the Panda bootloaders woud do on Blaze)
<Sage> OlivierN1: at least the panda bootloaders (and kernel) that I use on my mer adaptation boots on blaze.
<Sage> not sure how much things go wrong there though
<OlivierN1> fine, then you may install the Blaze bootloader package
<Sage> anyway thanks for the help so far. I'll try that kernel first and see if it changes things.
<OlivierN1> sudo apt-get install u-boot-linaro-omap4-sdp4430 and then sudo flash-kernel --update-bootloader
<rsalveti> janimo: hey, yes, the u-boot-linaro-stable at git.linaro.org
<rsalveti> janimo: you can also grab the package from our overlay if you want
<rsalveti> janimo: but jcrigby should be updating the package at ubuntu this week I believe
<ndec> ogra_: thx for the armhf... will look into that when my current task gets less crazy ;-)
<ogra_> just drop it and tell the people this is more important :P
<rsalveti> ndec: replied you back with the qt demo
<ndec> yep. i saw. does it work now?
<ogra_> rsalveti, seems didier is already merging it here, he promised me a package for testing this week during the sprint
<ndec> rsalveti: ok... i saw xavier's message. you should be enabled soon.
<ndec> that looks really good btw ;-)
<rsalveti> ndec: still waiting the package, should reply you back once I get it :-)
<rsalveti> ogra_: nux and unity are already merged
<ogra_> ah, so its just compiz then
<rsalveti> ogra_: now the problem is compiz
<rsalveti> on, unity is not yet merged
<rsalveti> but almost there
<ogra_> he didnt tell me what exactly is missing, we just talked on the corridor
<rsalveti> nux is the one that got at trunk
<rsalveti> compiz is the most complicated bit
<janimo> rsalveti, thanks. I just saw there's a blueprint for unifying omap SPL
<rsalveti> janimo: yup
<rsalveti> ndec: great, it works fine with latest driver from xavier
<dcordes-web> hi, can ac100 image related topics be discussed here ?
<ogra_> dcordes-web, sure, here or in #ac100
<dcordes-web> ok I have the following problem after apt-get update on my ac100 oneiric release image:
<dcordes-web> Failed to fetch bzip2:/var/lib/apt/lists/partial/ports.ubuntu.com_ubuntu-ports_dists_oneiric-updates_multiverse_binary-armel_Packages Hash Sum MismatchFailed to fetch bzip2:/var/lib/apt/lists/partial/ports.ubuntu.com_ubuntu-ports_dists_oneiric-security_multiverse_binary-armel_Packages Hash Sum Mismatch
<ogra_> janimo, are you sure the ac100 kernel in oneiric is in -updates ? or was that just -proposed
<ogra_> seems dcordes-web isnt getting it
<janimo> ogra_, infinity supposedlyt pushed it to updates 30 min or so ago
<ogra_> oh, and is the meta also uploaded to -proposed/-updates ?
<janimo> ogra_, there was no ABI bump, no meta needed AFAIK
<ogra_> else he wont get the update indeed
<ogra_> ah, k
<ogra_> well, then lets blame infinity
<dcordes-web> ogra_: infinity ?
<dcordes-web> ogra_: can I assume everything is ok on my side ?
<janimo> dcordes-web, not sure. Wait an hour or so and try updating again
<janimo> if you get apt-get update errors it is unrelated to the new kernel
<infinity> Patience? :P
<ogra_> pfft
<ogra_> infinity, its 16:34 btw
<infinity> linux-ac100 | 2.6.38-1001.2 | oneiric-proposed/universe | source
<infinity> linux-ac100 | 2.6.38-1001.2 | oneiric-updates/universe | source
<ogra_> (that time where one is supposed to go out and smoke )
<infinity> ogra_: Also, feel free to dogpile on https://bugs.launchpad.net/ubuntu/+source/unity/+bug/913237
<ubot2`> Launchpad bug 913237 in unity "Useless scroll arrows in menus" [Undecided,Confirmed]
<infinity> ogra_: Or bring it to the attention of the Unity devs you seem to friendly with. :P
<ogra_> oh, thanks
<GrueMaster> why don't you set up a cron job to pop up a message every hour?
<ogra_> i was actually planning to show it to the desktop guys directly later
<infinity> s/to friendly/so friendly/
<ogra_> GrueMaster, that wont add the proper randomization
<ogra_> its not exactly 60min
<dcordes-web> if I run upgrade now ( before that 1001.2 upload ) should I not get another kernel than 1000 =
<dcordes-web> ?
<dcordes-web> e.g. 1000.1 ?
<infinity> dcordes-web: Update and upgrade now should get you 1001.2
<infinity> dcordes-web: In theory.
<infinity> dcordes-web: Unless ports is broken.
<dcordes-web> infinity: ok update; upgrade
<dcordes-web> 269 to be updated :D
<infinity> Oh.  Been awhile? :P
<infinity> You might want dist-upgrade, if it's been that long.
<dcordes-web> no, I ran this many times
<dcordes-web> infinity: just minutes before
<dcordes-web> infinity: apt-get install linux-ac100 gave me 2.6.38.1001.1
<infinity> dcordes-web: Weird.  Ports might be lagging.
<dcordes-web> infinity: still no 1001.2 in my repos
<dcordes-web> thanks for the help everybody keep up the great work
<dcordes-web> bye
<sveinse> Does anyone know about a (good) tool for downloading all packages needed for a system? I know its a bit OT, but I want to collect all (armel) debs needed for a system and I haven't found any suitable tools when I want to download armel packages on an intel system. There is apt-offline, but I can't get it to work for armel
<ndec> ogra_: you there?
#ubuntu-arm 2012-01-10
<reisei> hi, all! Please, advice me, how can I build kernel on the x86 and then replace it on the arm device?
<reisei> I had try to follow https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel But there is no such directory: debian in the the ti-omap4 branch ...
<twb> reisei: you're cross-compiling, that adds a layer of complexity
<twb> The debian/* files will only be present in git branches that are from debian/ubuntu, and even then maybe not.
<twb> When I'm *not* cross-compiling, I use the upstream-provided mechanism of "make deb-pkg" -- I don't know if this is recommended or if it works with cross-compilation.
<reisei> twb: thank you! I'll try this
<twb> If you don't have a cross-compile environment yet, you need to solve that problem first
<reisei> twb: btw, in the master branch there are the debian directory
<twb> master branch from where?
<reisei> twb: from kernel.ubuntu.com, for example ubuntu/ubuntu-maverick
<twb> Well I guess that is a "git branch from debian/ubuntu"
<twb> As opposed to linus-2.6 or some other upstream branch
<twb> I'm not a dev so my understanding of current best practice is pretty haze -- don't take anything I say as gospe
<twb> *gospel
<reisei> twb: yes, it is a "git branch from debian/ubuntu" :) I understand, that directory debian can be only in such gits, but I'am just interesting why in the ti-omap4 branche of this git there is no such directory :)
<twb> Probably the ti-omap4 branch comes straight from upstream or something
<reisei> got an error while make deb-pkg: dpkg-gencontrol: error: current host architecture 'armel' does not appear in package's architecture list (i386)
<twb> You probably need to do some magic dance
<twb> The other way you can do it is to just run arm code in a chroot on your x86 box, using qemu user-space emulation
<twb> What that does is basically leave everything as-is except the CPU instructions, so it's lightweight compared to a normal VM
<reisei> okay :) will go to learn some magic things
<twb> http://wiki.debian.org/QemuUserEmulation
<twb> Note you will probably need qemu 1.x due to http://bugs.debian.org/641270
<reisei> twb: thanks a lot!
<twb> Eh, cross compilation is probably less sucky but I don't like grabbing unsigned tarballs from linaro or whatever
<reisei> twb: I just need recompile the kernel...
<twb> reisei: I mean: unsigned tarballs of the cross-compilation environment
<reisei> oh, okay
<twb> or maybe they're signed but not by ubuntu, etc.
<alum1> Hi may I have a question about i.MX53 based board and Ubuntu? I have trouble to boot Oneiric
<alum1> QuickStart image.
<alum1> I have Nitrogen53 board with i.MX53. Originally board comes with Android on SD card, I re-write it with QuickStart Oneiric image
<alum1> When I am trying to boot kernel and initrd, board always froze or (at best case says that is loading linux kernel and than froze)
<alum1> What I am doing after board starts :
<alum1> fatload mmc 0:2 0x70000000 uImage
<alum1> fatload mmc 0:2 0x72000000 uInitrd
<alum1>     setenv bootargs console=tty0 console=ttymxc0,115200n8   root=/dev/mmcblk0p3
<alum1>     bootm 0x70000000 0x72000000
<ogra_> we only support the original quickstart from freescale ....
<ogra_> but if you can make your board work, we would love to get patches ;)
<alum1>  and is there any (technical) reason, why this board will not work?
<alum1> I suppose, that problem is more in u-boot loader than in image itself
<ogra_> either u-boot or a missing/superfluous kernel driver
<ogra_> could be both, hard to guess without having the board
<alum1> I'am not terrible experience in u-boot and arm architecture, so I am trying what's working and what's not
<alum1> And how can I debug it and find out what it can be?
<ogra_> well, the nitrogen is clearly different from the quickstart
<ogra_> i would start with replacing the u-boot binary on the image with the one you got with the board (if you got one) and see if it works then ... (i.e. try to identify if its rather bootloader or kernel related)
<ogra_> not sure if your android image actually has u-boot or something else
<alum1> ok
<alum1> Please correct me if I am wrong. I have u-boot on board flash and is is also on sd card at first partiton (made by zcat of ubuntu image}. So I need to take u0boot from board flash and place it on cd card, right. That's what you meant?
<GrueMaster> alum1: YYou can add earlyprintk=ttymx0,115200n8 to your boot cmdline to get early kernel output.
<GrueMaster> If your uboot is loading the kernel, thiswould be the next step to see where the kernel s breaking.
<ppisati> guys, why don't we ship images with "support" for serial console out of the box? e.g. console=ttyO2,foobar and /etc/init/ttyO2.conf?
<ogra_> we do ... the server image ;)
<infinity> I think the argument is that "desktop" users will have a display and keyboard, an they might want to use the serial port for other things.
<infinity> Whereas "server" users are more likely to want a headless serial setup.
<infinity> But I dunno.  It's fairly arbitrary.
<ogra_> beyond that there is a longstanding upstart bug that it should automatically fire up a getty if a serial console is defined
<ogra_> (which is simply not fixed because nobody uploaded the fix from the bug yet )
<ogra_> ppisati, infinity, bug 702574 .... someone needs to upload this :)
<ubot2`> Launchpad bug 702574 in upstart "getty should be started automatically on serial port when serial console is set on kernel command line" [Wishlist,New] https://launchpad.net/bugs/702574
<ppisati> btw, did you see this one? http://www.alwaysinnovating.com/products/hdmidongle.htm
<infinity> ppisati: That's pretty slick looking.
<infinity> ppisati: Can our omap4 kernel boot it? :)
<ndec> ubuntu works on this dongle, yes.
<ndec> see http://groups.google.com/group/pandaboard/browse_thread/thread/dd881aa34e1a916e
<ndec> we work regularly with gregoire who did this, and he is using our Ubuntu releases a lot!
<infinity> ndec: Very cool.
<ndec> so should ubuntu TV ;-)
<infinity> ndec: So, slapping an Ubuntu preinstalled omap4 image on an SD for that dongle should "Just Work"?
<ndec> i asked gregoire to send me one so that I could try ...
<ndec> i don't know the details of the h/w and if that requires updates in bootloader/kernel. but 11.10 should be pretty close to work on the device
<infinity> Would definitely like to see 12.04 support it out of the box if 11.10 doesn't.
<infinity> I'd happily take a sample to play with. ;)
<ndec> no doubt about that ;-)
<ppisati> Ubuntu TV on a stick! :)
<ndec> no need to find TV makers... works on all TVs !
<ppisati> ndec: are they using a 4430 or 4460?
<alum1> GrueMaster: earlyprint didn't show anything. I can see just "Starting kernel ..."
<ndec> earlyprintk might help ;-)
<GrueMaster> So that means the kernel is not initializing.  The output you see is u-boot forking into the kernel, but the kernel is not executing.
<ndec> GrueMaster: alum1: see ^^ you need a 'k' at the end
<GrueMaster> I assumed he copied what I had above.
<GrueMaster> [09:54:19] <GrueMaster> alum1: YYou can add earlyprintk=ttymx0,115200n8 to your boot cmdline to get early kernel output.
<suihkulokki> even without earlyprintk you should see "Uncompressing Linux..."
<alum1> I see just "Starting kernelâ¦", nothing more
<suihkulokki> alum1: that suggests that the location where uboot is jumping to does not have a valid kernel
<alum1> suihkulokki: how can I check that?
<ogra_> infinity, does that look sane to you ? http://paste.ubuntu.com/799233/
<infinity> ogra_: Looks shockingly similar to what I uploaded 10 minutes ago. ;)
<ogra_> :P
<infinity> Who needs nicotine?
<reisei> infinity: what about vodka?
<ppisati> has anyone tried to kexec into u-boot?
<NCommander> ppisati: I don't think anyone tried it as kexec sets up ATAGS and other voodoo to boot a kernel directly so you'd have to smack uboot to ignore that info and other fun stuff
<ppisati> NCommander: uhm, ok
<marvin24> janimo: thanks for taking care of the new kernel so quickly
<janimo> marvin24, np :)
<marvin24> looks like google found the bug in 3.0.13
<janimo> it made evertyone's ac100 around here lock up every our or so otherwise
<janimo> oh great
<marvin24> but I'll test it first
<janimo> any work going on on 3.2/3.3 on google's behalf?
<marvin24> janimo: yeah, I guess that was a bad experience
<marvin24> janimo: there are hacks for upstream
<janimo> well, development version of Ubuntu, anm assumed risk
<marvin24> but we shouldn't use them
<marvin24> janimo: last I heard was that someone at NV is working on a KMS driver
<marvin24> but maybe at a low priority
<marvin24> but that is the way to go for us
<marvin24> just wait ~half a year
<janimo> as opposed to te binary l4t drivers?
<marvin24> well, kms mean framebuffer only
<marvin24> but maybe they will also do a 3d driver for it
<marvin24> the current kernel implementation is definitely not for upstream
<marvin24> in that case NV is way behing TI, Marvel or Samsung
<ogra_> janimo, http://patchwork.ozlabs.org/patch/35501/ for quietening the ac100 boot
<pakattack> On which arm board, the beagleboardxm or the pandaboard es, will a ubuntu server be best for?
<k1l_> Anyone tried smth with the HP Touchpad or a similar Tablet?
<pakattack> I am trying to build a microserver and want to know on which board ubuntu server runs better on, the pandaboard es or the beagleboard xm?
<pakattack> Anyone?
<OlivierN> yet another random guy who ask, nag and quit.
<k1l> welcome to the irc :)
<OlivierN> at least now I am checking that the guy is still there before preparing an answer
<pakattack> Which runs ubuntu server better, pandaboard es or beagleboardxm?
<infinity> pakattack: Panda.
<k1l> pakattack: i dont know the answer, but this channel is very quiet. so you have to bring some patience
<k1l> :(
<infinity> pakattack: If you missed my response, I said that the Panda will certainly run just about everything better than the Beagle.
<pakattack> Ok thanks
<Arcademan> May I ask where I might find what ISO I would need for my Archos device?
<sauerbraten> you have to find out which ARM platform it is based on I think.
<sauerbraten> Arcademan: ^
<Arcademan> Ok, so like ARM Cortex A8
<sauerbraten> what tablet is it? maybe I can find something for you then
<Arcademan> Please see https://wiki.kubuntu.org/ARM/Archos101it
<sauerbraten> OMAP3 then
<sauerbraten> Arcademan: choose your edition and versin here https://wiki.ubuntu.com/ARM/OMAP , then go for the omap3 build
<sauerbraten> also just "omap" in the file names
<sauerbraten> that should work I guess
<Arcademan> Ok, so I take it I must use the omap then I take it the devices does not support the desktop edition :)
<sauerbraten> wait, what? according to wikipedia, the archos 101 internet tablet fits the OMAP3 category, so I think any omap3/omap build should run
<sauerbraten> not omap4 of course
<sauerbraten> archos 101 g9 is omap4 thoug
<Arcademan> Ok may I ask one last question whats the real diff between desktop and server is the server one ubuntu server
<Arcademan> I see that on Wiki the Omap thing :)
<sauerbraten> I think the server one comes without X and has special packages preinstalled and repos configured
<sauerbraten> you can add X to server, though
<sauerbraten> you can also install all server packages on desktop of course
<sauerbraten> just a matter of what you think fits your needs better I guess
<Arcademan> Ok, sauerbraten I try it out this next week or so thanks :)
<sauerbraten> np, hope it goes well for you, since I got few problems with earlier versions on omap4 :D
<Arcademan> I will be playing around with it trying to figure out what desktop package works the best ex kde ect :)
<Arcademan> They have a debian release I may try and fork over some of them :P
<sauerbraten> eww, KDE :P I prefer XFCE or LXDE, some lighter stuff :) but well, matter of taste
<Arcademan> me to sauerbraten :P
<Arcademan> I just did not want to use the dang Android :P
<kerute> hello
<kerute> any idea on how i can flash a new kernel on my eeepad transformer ?
<kerute> flashed ubuntu with OLife
<lilstevie> kerute: there are 2 ways
<lilstevie> kerute: one way is to replace ./kernels/2636zImage and ./kernels/initrd.img-2.6.36 in the OLiFE directories, then in the update device menu select update kernel.
<lilstevie> kerute: the other is to make a boot.img from your kernel and ramdisk, pack it in a nvblob and dd it to /dev/mmcblk0p4
<kerute> lilstevie_: i think about nvflash ?
<kerute> nvblob ?
<kerute> first one seems easier :)
<kerute> lilstevie_: what about the 2.6.38 in OLiFE ?
<kerute> is that the CrOs kernel ? the script says the option is unavailable
<kerute> thanks for the advice ill try that
#ubuntu-arm 2012-01-11
<ogra_> lilstevie, around ?
<brendand> hey, does the hard-float image work on the pandaboard?
<ogra_> sure
<brendand> does it make any difference?
<ogra_> it fells faster, i didnt measure anything myself
<ogra_> so thats a totally subjective impression
<brendand> yeah, that might be an interesting experiment
<lilstevie> ogra_: kinda, redecorating bedroom
<lilstevie> ogra_: if you are about I am here now :)
<ogra_> lilstevie, i was wondering if you have anything newer for the transformer than 2.6.36
 * ogra_ is just playing with an ubuntu installed transformer and the kernel seems to have some issues
<ogra_> though the config is a bit odd anyway
<lilstevie> the config is a bit off yeah, been working on some things though
<lilstevie> I will have something newer soon
<ogra_> but you are on the same source ?
<ogra_> k
<lilstevie> well I am working on bringing it over to mainline
<lilstevie> there is the 2.6.38 CrOS kernel if you are using u-boot though
<ogra_> not sure they use u-boot on this device
<ogra_> its not mine, i just got it to look at some performance issues
<lilstevie> ah,
<lilstevie> yeah probably stock bootloader then
<ogra_> (and noticed a bunch of udev errors on boot)
<lilstevie> hm
<ogra_> looks like it doesnt have dnotify enabled and other minor things
<lilstevie> can you grab the config from /proc/config.gz and see what the generation date is?
<ogra_> # Linux kernel version: 2.6.36.4
<ogra_> # Tue Jan  3 09:26:31 2012
<ogra_> but i think they recompiled the kernel already
<lilstevie> wow
<lilstevie> jan 3
<lilstevie> :p
<lilstevie> thats not my kernel
<lilstevie> :p
<lilstevie> but it is built off the latest probably
<lilstevie> there are some odd things missing from the config, I am aware of that, and I have been adding them as I have been made aware of them
<brendand> ogra_ - any chance the hf images might not work on older pandaboards?
<lilstevie> although, can't say I have seen any udev errors
<ogra_> define older
<brendand> i have an A1 and it isn't going anywhere
<ogra_> we tested onm EA1 which is even older
<ogra_> *on
<brendand> okay
<infinity> Define "not going anywhere"?
<brendand> maybe it's just the latest image then
<infinity> Usually that's a bad SD, or a a badly-seated card.
<brendand> hmm
<GrueMaster> brendand: I have run it on every HW revision board I have (EA1-A3 & 4460).
<brendand> well, the light pattern seems a bit weird. not what i usually see
<GrueMaster> And I have today's daily image running now on 4460.
<GrueMaster> Precise kernel doesn't blink the led's like maverick-oneiric kernels did.
<brendand> when i switch my monitor to the dvi input, it just switches back again. that usually means nothing being output on the dvi
<GrueMaster> brendand: That is a different issue (and one I haven't tested).
<GrueMaster> Try the HDMI port.
<brendand> jeez
<brendand> all of a sudden it's the HDMI port that needs to be used. great
<GrueMaster> Erm, that has always been the case.
<GrueMaster> At least that is how I have tested since Maverick.
<brendand> oh well, no worries
<kerute> hello
<kerute> lilstevie_: sorry to bother you, if i want to try the 2.6.38 in OLiFe, what should I do ? i tried to flash using the 'update cros kernel' or by replacing the 2.6.36 with tne .38 but i either end up in initramfs shell telling me there is no mmcblk0p8 or stuck on 'asus' boot screen
<lilstevie> kerute: at this point, solve the reason why it wont read asus/nvidias bastardized gpt implimentation
<lilstevie> or use u-boot
<kerute> ok so u-boot i have to compile it from your repo (u-boot-tegra) and flash it using OLiFe ?
<lilstevie> yes
<kerute> ok thanks a lot
<kerute> for the first point i'm not sure i have enought knowledge :)
<ppisati> would kexec be a nice addition to our kernels?
 * infinity glances at #ubuntu-kernel
<ppisati> well, if you want it i need a bug to be opened against our P kernels
<ppisati> teh patchset is quite big, but it works
<ppisati> so i won't backport it to O
<infinity> ppisati: I didn't say I wanted it.
<infinity> ppisati: Do the x86 Ubuntu kernels have kexec?
<ppisati> yep
<ppisati> it was broken on arm
<ppisati> but a series of patches make it work on arm now
<infinity> Ahh.  Well, I'm a fan of our ARM kernels mirroring the x86 ones.
<ppisati> yep
<infinity> Just as an element of least surprise.
<ppisati> the problem is that all the stuff is in 3.3
<ppisati> and the backport for omap-only is about...
<ppisati> ~17 ptches ATM
<ppisati> the entire patches with all the archs is about...
<ppisati> 70 patches? more or less
<ppisati> sorry, with all the arm chips
<ppisati> and i want to apply it to master
<ppisati> so i'll percolate down to all the topic branches
<ppisati> it'll
<ppisati> (can't type today...)
<GrueMaster> iirc, kexec was attempted multiple times on arm.  seems to come up every cycle.  I think there is an old blueprint on it.
<GrueMaster> ppisati: do a google search:  arm kexec site:launchpad.net
<GrueMaster> lots of entries.
<ppisati> GrueMaster: cool
<ppisati> there's still an issue
<ppisati> but it's workable
<ppisati> aka nic is dead after kexec
<GrueMaster> How is this considered "workable"?
<ppisati> in the sense that it's an isolated fix
<ppisati> some stuff is not initialised properly in smsc911x
<ppisati> and when it boots from u-boot is ok
<ppisati> else it craps out
<calculus> I have ubuntu 11.10 on a pandaboard, did apt-get dist-upgrade, connected a tv to the hdmi port, and video works, but I am trying to get the audio to come out on the tv as well... any ideas?
<calculus> is there something in alsamixer that needs to be turned on/unmuted?
#ubuntu-arm 2012-01-12
<NotJimCarrey> anyone know what "for thumb inter-working we require an architecture which supports blx" means when i try building node.js in an ARM environment?
<twb> blx is probably an instruction
<twb> http://infocenter.arm.com/help/topic/com.arm.doc.kui0100a/armasm_cihfddaf.htm
<twb> IIUC it's how you tell the CPU to swap from arm instructions to thumb instructions
<twb> Sounds like you're on an M profile ARMv7 core and you simply can't have that.
<NotJimCarrey> know how to add it?
<twb> Get a different CPU
<NotJimCarrey> lol
<NotJimCarrey> ok, know a way around it?
<twb> Or it may be you're compiling for a lowest-common-denominator that doesn't include that, although your actual target hardware does
<twb> It may also be that BLX is only needed because that's what node.js source knows how to use, and you can either HTFS or node.js, or compile it to thumb-less ARM
<NotJimCarrey> um, huh
<NotJimCarrey> all i know is i have a Texas Instruments OMAP3530 system-on-chip with ARM Cortex-A8
<twb> FWIW on oneiric, apt-get source nodejs; ./configure --without-ssl worked for me
<lilstevie> that would seem odd
<lilstevie> thumb is part of armv7
<lilstevie> and there is no other way to switch between thumb and arm other than BLX
<NotJimCarrey> trying --without-ssl
<NotJimCarrey> same error
<twb> lilstevie: I suspect he's doing -march armv4 or something, implicitly.
<NotJimCarrey> i tried make CFLAGS=-march=armv5t earlier, but no go
<twb> lilstevie: ARMv7-M apparently lacks BLX
<twb> Ref. previous link
<NotJimCarrey> should it be "make CFLAGS=-march=armv5t" or "make CFLAGS='-march=armv5t'"?
<lilstevie> -march is going to fail
<lilstevie> :p
<lilstevie> well not going to fail
<lilstevie> but is fail
<lilstevie> if you are targetting ubuntu-arm you should be targetting armv7
<lilstevie> so -march=armv7
<NotJimCarrey> thought armv7 didn't support blx?
<lilstevie> all armv7 except armv7-m do
<NotJimCarrey> ah
<NotJimCarrey> ok, do i add CFLAGS=-march=armv7 to make or configure?
<NotJimCarrey> nm, obvioulsy not configure since that didn't work
<twb> CFLAGS may not be being passed the way you expect
<NotJimCarrey> hrmm, "make CFLAGS=-march=armv7" returns "target CPU does not support ARM mode"
<lilstevie> 0.o
<NotJimCarrey> ok, looking through macro-assembler-arm.cc, i found the error message with "If you know what CPU you are compiling for you can use -march=armv7 or similar", but how am i suppose to use it
<twb> You probably need to pass it to waf in some manner like ./waf --extra-ccflags
<twb> Note also nodejs v8 code appears to be C++ not C, so CXXFLAGS not CFLAGS
<NotJimCarrey> ah
<twb> Or both, or whatever
<twb> Usually when dealing with this kind of thing you end up having to debug / rewrite upstream's idiotic makefile / configure.ac / wscript / whatever
<NotJimCarrey> lol
<NotJimCarrey> well, "make CXXFLAGS=-march=armv7" gave me the no arm support error, bot "make CXXFLAGS=-march=armv5t" is still going
<NotJimCarrey> yay, still going
<NotJimCarrey> dammit, now getting: pure virtual method called. terminate called withough an active exception
<twb> Why are you compiling nodejs anyway
<NotJimCarrey> for koush
<NotJimCarrey> oops
<NotJimCarrey> for koush's tether app, so it can run on arm systems (specifically, openpandora)
<twb> NotJimCarrey: I mean, why don't you just apt-get install it
<NotJimCarrey> tried using it, but got errors
<twb> Did you investigate them?
<NotJimCarrey> think koush modified it for tap/tun support
<calculus> how can I get audio over hdmi (ubuntu 11.10 on pandaboard)?
<NotJimCarrey> if i run the script with the node.js from the angstrom repo, i get "unable to open tun/tap device"
<twb> That's more likely to be either a permissions issue or you don't have a tun or tap device yet
<NotJimCarrey> well, running it sudo because it uses adb
<twb> blergh
<twb> Well, whatever.
<ogra_> infinity, Bug 890261
<ubot2`> Launchpad bug 890261 in ubiquity "can not execute oem-config in a chrooted environment" [Medium,New] https://launchpad.net/bugs/890261
<infinity> ogra_: Danke.
<janimo> ogra_, http://kernel.ubuntu.com/git?p=jani/ubuntu-ac100.git;a=shortlog;h=refs/heads/packaging-chromeos-ac100-3.0
<janimo> UBUNTU SAUCE commit, seventh from top
<janimo> that should be the quietening patch
<janimo> but it doesnot seem to have effect on mine either
<ogra_> weird weird
<ogra_> probably the bits we actually see are not using the proper kernel interface
<ogra_> (the logging functions i mean)
<ogra_> it all seems to come from non std drivers
<ogra_> i.e. the < ... > i see seem to come from tegrapart
<ogra_> janimo, http://git.chromium.org/gitweb/?p=chromiumos/third_party/kernel.git;a=commitdiff;h=7abaad6c574bbdc0dd66820eaf006857dac6c4e7
<ogra_> sight
<ogra_> (commit from tonight)
<ogra_> *sigh even
<janimo> ogra_, yeah, I hopemarvin24 picks those up too and takes out the unneeded options from defconfig. I'll NFS and the other important ones so we keep the config delta minimal
<ogra_> janimo, well, i'm not really thrilled about losing power management completely
<janimo> ogra_, well if it seems that is does not affect ac100 we can leave it on
<ogra_> right
<janimo> the latest kernel (3.0.8 from stable) is stable so far
<ogra_> seems a bit broad to just disable it for all tegra
<mythos> hello there
<mythos> i have a little question. i see, there are kernel-flavours for different arm-based devices. but they use the same repository, i guess. am i right?
<mythos> sorry, but where do i find an arm-rootfs for a qemu-chroot environment?
<mythos> or is debootstrap the way to go?
<OlivierN1> mythos: kernel can be easily cross-compiled. For other components, there are various solutions but generally native ARM build is the safest (tough often slowest)
<OlivierN1> *though
<mythos> thank you, OlivierN1
<mythos> but i'm not so far that i can go on a real hardware
<marvin24> janimo: if the kernel turns out to be stable, you may activate the frontswap option in the next cycle
<mythos> so i would be happy, if i got a running chroot environment with qemu-static-arm, so i can start to mess around
<marvin24> so people don't need to mess around with zram/swap stuff anymore
<janimo> marvin24, 3.0.13 you mean?
<marvin24> janimo: no, it is there in 3.0.8 already
<marvin24> just not on by default
<OlivierN1> mythos: other people here can help on the qemu front. Personally I use native build.
<janimo> ok, 3.0.8 is stable using your stable tree
<janimo> been running since yesterday without lockup
<marvin24> nice!
<janimo> any news on 3.0.13? Is that the latest version that chromeos works on?
<marvin24> still haven't found the bug in 3.0.13 <- not so nice
<mythos> OlivierN1, no problem. i found a good tutorial for debian using multiarch. i'm going to try and hope for the best =)
<mythos> hmm.... where do i find the arm-debs for eg maverick? ^^"
<mythos> ah, found it: ports.ubuntu.com
<janimo> lilstevie, do you know if anyone is working on a 3.x based transformer kernel?
<kerute> i'd like to know that too :)
<lilstevie> janimo: at present no
<lilstevie> janimo: working towards it though
<janimo> lilstevie, ok, thanks :)
<janimo> anything in common with the ac100/chromeos tree?
<janimo> It'd be nice if we could share the same package in ubuntu for as many tegra based hw as possible
<lilstevie> janimo: more in common with ventana
<lilstevie> janimo: that is possible
<lilstevie> janimo: ac100 bl reports harmony while tf101 reports ventana, so no messy hacks would be required either
<mythos> OlivierN1, for a native built-environment, do you use a nfs-rootfs for the arm-device?
<OlivierN1> mythos: brb
<OlivierN1> mythos: you may use NFS, SD card, eMMC, USB stick, etc. But the fastest by far (at least on Panda board) is a USB hard drive, especially for native build.
<mythos> OlivierN1, thanks for the advice =)
<mythos> i was able to get a chroot environment, so i'm quite happy =D
<Sage> how is one supposed to create .config for http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=commit;h=f0fb3e7b7b2f8c791802e136293e8aadaac14119 ?
<Sage> not using debian or ubuntu
<ogra_> then why do you ask in an ubuntu channel ?
<Sage> because it is ubuntu kernel and I just want to get the configs out of it to see them as whole
<Sage> so wondering what command does the kernel config for omap4 there
<ogra_> they are in the debian dir split in multiple chunks usually
<ogra_> and merged at build time
<Sage> so omap4_defconfig doesn't do it as I assumed.
<ogra_> omap4_defconfig will work if yuo just use make (its an upstream config after all) but not get you the same as an ubuntu package
<Sage> well, I want to have the same as in ubuntu thus asking
<ogra_> if you want the ubuntu config you will have to use dpkg-builpackage or call debian/rules which triggers the various scripts before rolling the package
<Sage> hmmp
<Sage> ok, where are the .deb files for that kernel there is config in those :)
<ogra_> but you are probably better off to download the binary package from the archive, unpack it and pull /boot/config-$kernelversion out of the package
<ogra_> either on launchpad or in the pool on prots.ubuntu.com
<ogra_> *ports.
<OlivierN1> Sage: this page may help: http://omappedia.com/wiki/Ubuntu_kernel_for_OMAP4  (section 4.1)
<Sage> OlivierN1: well on fedora it is not so straight forwardhttp://pastie.org/3173223
<Sage> err http://pastie.org/3173223
<Sage> ti-ubuntu-3.0-1281.7 <- this is what I'm looking for atm. but can find only these https://launchpad.net/ubuntu/+source/linux-ti-omap4
<infinity> Why live in the past?
<Sage> if you mean that 3.2 thing those are not in http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=summary
<infinity> http://loki.0c3.net/~adconrad/config-3.2.0-1403-omap4 <-- The current config
<Sage> ok, thx. And any knowledge if that works on blaze as well (screen, touch etc)?
<infinity> Maybe?  Not sure, don't have a blaze.
<OlivierN1> Sage: at least ti-ubuntu-3.0-1281.7 works on Blaze (LCD and touch screen are  OK, sound record/playback is upcoming)
<Sage> OlivierN1: ok, where to get the tarball and .deb for that?
 * Sage really don't know where to find those in launchpad
<OlivierN1> Sage: TI public PPA is here: https://launchpad.net/~tiomap-dev/+archive/release
<OlivierN1> (but it does not contain 3.x kernel for now)
<ogra_> https://launchpad.net/ubuntu/+source/linux-ti-omap4 has all debs that were ever built in ubuntu
<Sage> OlivierN1: exactly :)
<Sage> OlivierN1: you don't happen to have .deb for that ti-ubuntu-3.0-1281.7 or even just the config from /boot/?
<OlivierN1> Sage: basically TI PPAs is always a little behind TI trees. For now we do not consider ti-ubuntu-3.0-1281.7 as stable enough to upgrade PPA
<Sage> OlivierN1: yes, well. You said ti-ubuntu-3.0-1281.7 works on blaze so you have compiled it and have config somewhere?
<OlivierN1> sure
<Sage> I'm really looking just kernel that has been tested on blaze and works, don't care so much if it is stable or not, just want to boot the damn thing and see and then think stability :)
<Sage> OlivierN1: want to share the config? :)
<OlivierN1> Sage: config-3.0.0-1281: http://pastebin.com/2HKn0wvS
<Sage> OlivierN1: thx
<Jef91> Where can I find the source archives/.debs for Ubuntu ARMEL debs?
<mythos> ports.ubuntu.com?
#ubuntu-arm 2012-01-13
<rbasak> Is anyone aware of a regression in precise for pandas? Or any changes made since yesterday that might be relevant? I had an automated install working yesterday, but it is failing to boot after the installer today, and I haven't changed anything.
<infinity> rbasak: Not that I know of.
<infinity> rbasak: You mean fresh installs don't work, or a dist-upgraded one has failed to continue working?
<rbasak> fresh installs don't work
<rbasak> I'm just trying oneiric now to check it's not something not archive related
<infinity> There was a new kernel yesterday.  Could be broken, or the images could just be suffering from some archive breakage.
<rbasak> ok, thanks. I might ask for some help debugging this in a bit
<rbasak> OK I think there's a regression for panda in the new kernel. It just doesn't boot, no output after "Uncompressing Linux... done, booting the kernel.", even with quiet etc. removed from the command line. The installer works fine. Any help please?
<rbasak> or can anyone reproduce?
<janimo> rbasak, I know there was such a bug in omap4 kernel last Linaro release, worked around by passing a compiler flag
<janimo> but not sure about latest kernels
<Spider-Pork> I've followed this guide for booting from USB instead of SD card on my pandaboard. It boot but is really, really slow and the board seems to continuosly access USB HD. I'm using prebuild image for ubuntu 11.10 http://omappedia.org/wiki/Prebuilt_ubuntu_binaries. Is it normal? Thank you
<Spider-Pork> ops, ---> this guide http://omappedia.org/wiki/Ubuntu_on_OMAP_FAQ#I_want_to_install_Ubuntu_on_external_USB_hard_disk_instead_of_sluggish_SD_card
<GrueMaster> Spider-Pork: Not sure what to tell you on that because I haven't tried that method.  I use the netinstall image to install to a USB drive (Sata) and it seems fairly responsive.
<Giovani_br> Hi, I would like to have a console terminal in the serial port, instead of the hdmi. How can I configure?
<GrueMaster> Giovani_br: Desktop image or server image?
<Spider-Pork> GrueMaster: oh is possible to install on external drive with netinstall?
<Spider-Pork> where you put the url to external disk?
<Spider-Pork> you put image of netinstall on SD right?
<Spider-Pork> and then from netinstall put external disk URL?
<Giovani_br> GrueMaster: server image, I am using pandaboard. I have the serial port connected the last message says: "stopping read required files in advance [ OK ]" then the login screen is displayed in the hdmi
<GrueMaster> It still requires an SD, but the rootfs & swap get installed on the usb drive.
<Spider-Pork> GrueMaster: ok but how you done it?
<GrueMaster> Giovani_br: The server image should create a login tty on the serial port.
<Giovani_br> GrueMaster: it is not creating ;/
<Giovani_br> ubuntu-11.10-preinstalled-server-armel+omap4.img this is the image
<Quintasan> ARGH
<Quintasan> ogra_: ping
<Spider-Pork> ok, you wrote it on your SD right?
<Giovani_br> GrueMaster: the login tty is on the hdmi port
<GrueMaster> Spider-Pork:  Download the netinstall image from http://ports.ubuntu.com/ubuntu-ports/dists/oneiric/main/installer-armel/current/images/omap4/netboot/
<GrueMaster> Spider-Pork: Use one of boot.img-[serial|fb].  The serial one puts the config screen out to the serial console, and the fb will run install from the screen.
<Spider-Pork> ok and then how you indicate URL for external drive?
<Spider-Pork> the alternate install ask to you?
<GrueMaster> Giovani_br: What do you have on the serial console?  Do you see u-boot messages?
<Giovani_br> GrueMaster: yes
<GrueMaster> Spider-Pork: The installer will have a section on guided partitioning.
<Giovani_br> GrueMaster: also linux messages
<Spider-Pork> GrueMaster: thank you!
<Giovani_br> but not the login
<GrueMaster> Giovani_br: Which image are you running?
<Giovani_br> GrueMaster: ubuntu-11.10-preinstalled-server-armel+omap4.img
<GrueMaster> Very odd.  I have that running here on one of my pandas.  It sounds like you either are missing /etc/init/ttyO2.conf, or it is corrupted.
<Giovani_br> I will see in the sd card
<reisei> \quit
<Spider-Pork> GrueMaster: on netboot installer, you have selected ubuntu desktop USB?
<Spider-Pork> *have you
<GrueMaster> No, select Ubuntu-desktop.  The other one isfor creating a live USBstick (and I think it is only for x86).
<Spider-Pork> ok tyhankyou
<GrueMaster> Spider-Pork: Are you using Oneiric?
<Spider-Pork> GrueMaster: 11.10+
<Spider-Pork> 11.10
<GrueMaster> Ok, cool.  Reason I asked was we have a broken kernel in the 12.04 pool atm.
<Spider-Pork> ok thank you
<Spider-Pork> i came from openembedded. How ubuntu create these prebuild images?
<ogra_> using the cdimage build servers in the canonical datacenter :)
<Spider-Pork> for example: on openembedded I utilize bitbake my_image_recipe
<GrueMaster> Magic fairy dust sprikled liberally over a lot of crappy scripts.
<ogra_> they are assembled from the binary debs
<Spider-Pork> ah ok
<Spider-Pork> so i can't build my own ubuntu
<Spider-Pork> i must wait prebuild images from canonical right?
<ogra_> the tool building the filesystem is called live-build but that only gives you the content of the second partition
<GrueMaster> You can, but I don't know how to get you started.  Others have before.
<Spider-Pork> so i must build kernel and uboot
<Spider-Pork> and boot.scr right?
<ogra_> the image itself and the partitioninjg are done with the scripts from cdimage
<Spider-Pork> ok
<Spider-Pork> thank you
<infinity> ppisati: *poke*
<Spider-Pork> i'll study this system better
<infinity> ppisati: Come join us in the ARM room for a second?
<Spider-Pork> is there a doc about these stuff?
<Spider-Pork> GrueMaster: are you sure about ubuntu desktop choice? After selected it nothing appeared then. Is blocked there, apparently doing nothing
<GrueMaster> Spider-Pork: Unfortunately, I am not in a position to reproduce this at the moment.  I am going by memory.
<GrueMaster> What are you seeing after the install finishes?  Just a login console?
<Spider-Pork> GrueMaster: simply freeze
<Spider-Pork> i see the coice for what kind of install i would
<Spider-Pork> and nothing more
<Spider-Pork> i rebooted
<Spider-Pork> I select again ubuntu desktop
<GrueMaster> Sounds like something isn't getting installed right.
<Spider-Pork> then apparently load packages and restart asking me locale, UTC, username, keyboard
<Spider-Pork> so on at while(1)
<Spider-Pork> is the third time i write the SD server installation
<Spider-Pork> I'm starting to think that this SD card has some problems
<GrueMaster> Wait, which are you running? preinstalled-server, preinstalled-desktop, or netinstall?
<Spider-Pork> preinstalled-server
<Spider-Pork> oh wait
<GrueMaster> And you are trying to get desktop running from that?
<Spider-Pork> yep
<GrueMaster> I thought you wanted to install onto a usb drive?
<Spider-Pork> oh my god
<Spider-Pork> I readen the wrong line
<Spider-Pork> you told me to use netinstall
<Spider-Pork> not server
<GrueMaster> Yes.
 * Spider-Pork take out his head from the ass
<GrueMaster> I need to shutdown and pack up.  I'll be back online Monday to help further (1400 UTC).
<Spider-Pork> thank you GrueMaster
<rajo> hello
<rajo> do anyone know how to extract omap armhf images
<rajo> I want to modify those files offline ?
<rajo> I have tried to mount, but with no luck
<ndec> you mean something like this : http://omappedia.org/wiki/Add_Packages_To_Ubuntu_Preinstalled_Images#Mounting_the_pre-installed_rootfs
<rajo> I will give it a chance. I am using Tegra2 based platform and want to test precise armhf port
<rajo> thank you
<ndec> the method in the wiki is exactly what you want to do I think!
<rajo> I hope so ...
<LetoThe2nd> rsalveti_: howdy. still remember poking the omap kernel and being intrigued by the '+' at the end of the name? in case you do, see https://wiki.ubuntu.com/KernelTeam/GitKernelBuild step 7 for where it comes from.
<rsalveti_> LetoThe2nd: cool, didn't know about this wiki page
<rsalveti_> something useful for people wanting to generate the deb packages from mainline
<rsalveti_> thanks
<LetoThe2nd> rsalveti_: np. whenever i stumble upon such things, i try t report back ;)
<LetoThe2nd> (though i admit its been a few days ;P )
<rsalveti> haha, np :-)
<LetoThe2nd> good night and have a nice weekend then :)
<rsalveti> you too, c-ya
#ubuntu-arm 2012-01-14
<pnphi> joined now
<pnphi> please give me your email,i have a problem.i need to help
<pnphi> joined
<pnphi> hello
<pnphi> Help me...Can i use "apt-get install ubuntu-desktop" in ARM ubuntu Qemu ?
<pnphi> joined now
<pnphi> Help me...Can i use "apt-get install ubuntu-desktop" in ARM ubuntu Qemu ?
<pnphi> Help me...Can i use "apt-get install ubuntu-desktop" in ARM ubuntu Qemu ?
<Hellhawk> Good Evening! I've got a problem with ubuntu 11.10 on my pandaboard. After I've installed the OMAP-packages ubuntu the x-server won't start and i get a bunch of error-message from ''nameserver_get_handle failed" to "ti_st_open: st_register failed -22". There are some google-hits but none with a solution. Can anybody help me? Thanks in advance.
<Hellhawk> please ignore my question, i'm getting help on #pandaboard already, thanks
#ubuntu-arm 2012-01-15
<mythos> hello, i downloaded the image for hp's 5335z (thinclient) here: http://tinyurl.com/7a7qpoy and found that the initrd (gziped ext2-file) is full of 386er binaries. can someone explain that?
#ubuntu-arm 2013-01-07
<koob_> hello all, Happy New Year
<koob_> is anyone dual booting Android and Ubuntu here?
<raster> mew
<koob_> mew
<prpplague> hmm, ok so who at canonical is in charge of support for panda these days?
<infinity> prpplague: Define "support".
<infinity> prpplague: Paolo still handles the kernels, but only for stable releases.
<prpplague> infinity: i.e. who is the best person to coordinate with for the new memory configuration patches?
<infinity> prpplague: Paolo.
<infinity> prpplague: You'll want to file a bug against linux-ti-omap4 as well.  For bonus points, let me know what the bug number is so I can open SRU tasks for all supported releases (assuming you intend to make said patches work for 3.0/3.2/3.5)
<prpplague> infinity: not sure if we need to back support the older versions
<infinity> prpplague: Well, to precise, at least.
<davecheney> has anyone managed to connect a bluetooth kb/mouse to their nexus 7 running 13.04 yet ?
<ubuntubhoy> Only used physical connections myself
<davecheney> ubuntubhoy: i'm not even sure bluetooth is working properly
<davecheney> the indicator applet lights up
<davecheney> but the control panel says bluetooth is off still
#ubuntu-arm 2013-01-08
<ubuntubhoy> as I say it's not one of the thing's I tried
<Noskcaj> anyone interested? http://viajemotu.wordpress.com/2013/01/07/ubuntu-loco-games-2013-1/
<mattronix> hello
<mattronix> has anyone used ubuntu arm on a raspberry pi
<hrw> marvin24: you can't
<hrw> "If you have a Pi, try #raspbian !" is in topic for a reason
<infinity> hrw: You meant mattronix, which failed to tab-complete cause he left. :P
<lilstevie> hrw: I was about to say that but the guy left
<hrw> ops
<ppisati> ikepanhc: do you use DT with any of your arm kernels?
<janimo> ppisati, the armadaxp at least does not use DT
<ppisati> uhm
<janimo> ppisati, not sure about other kernels ike maintains
<ppisati> i'm rpetty sure at leat one of our kernel support DT
<janimo> armadaxp support may be in 3.8 already so in raring we could just switch to mainline. I know it is being upstreamed but I am not uptodate
<hrw> and if is then probably also uses DT
<ppisati> my concern is about ubuntu arm images vs DT distribution/board support
<ppisati> do we separate DTs from ubuntu images?
<ppisati> or do we only support one board?
<ppisati> e.g. for omap4 there are already 2 different DTs
<ppisati> panda and pandaes
<ppisati> which do we pick?
<hrw> both and let uboot choose?
<ppisati> hrw: does the linaro alredy do that?
<ppisati> hrw: *linaro uboot
<hrw> ppisati: no idea - I no longer touch armv7a
<ikepanhc> ppisati: besides armadaxp, highbank and arndale require DT when booting
<ppisati> ikepanhc: arndale?
<ikepanhc> ppisati: samsung soc
<hrw> exynos5250
<ikepanhc> exactly
<hrw> nice devboard for development of arm stuff. dual a15 with 2gb ram and sata
<ppisati> ikepanhc: do you know where DT is distributed? in u-boot or in the kernel package?
<ikepanhc> ppisati: DT binary shall be something bootloader hands over to kernel, usually bootloader will put it in dram
<hrw> ppisati: should be with kernel
<ikepanhc> ppisati: in my viewpoint, it shall not be with kenel package
<suihkulokki> it comes from the kernel sources so
<hrw> ikepanhc: but it comes from kernel source
<ppisati> ikepanhc: in the armadaxp case, where does it live?
<ikepanhc> yes, in all of the case I see, all from kernel source
<ikepanhc> but just like acpi table, if we just need a single table for a kernel, why we need it?
 * ppisati download armadaxp and take a look
<hrw> ikepanhc: because we can provide single table for device which runs kernel targetting 100 different devices?
<ikepanhc> hrw: I think it shall be designed for "single kernel can work fine on 100 different board with each DT"
<ikepanhc> ppisati: armadaxp do not have DT support
<hrw> ikepanhc: if you want 4MB kernel with 4MB DT...
<hrw> ikepanhc: there are devices where DT will be manipulated from userspace
<RaYmAn> isn't that purely a hack to get around missing DT support in bootloaders though?
<hrw> RaYmAn: no
<hrw> RaYmAn: https://lwn.net/Articles/531569/
<marvin24> hi janimo
<marvin24> I've setup a branch on http://gitorious.org/~marvin24/ac100/marvin24s-kernel/commits/linux-ac100-3.8
<marvin24> with some patches against 3.8-rc2
<marvin24> I'm not sure how to proceed
<marvin24> as there will be no official Raring build for the AC100
<marvin24> on the other hand, a kernel package would make it simpler to create a community build
<marvin24> I wonder if there is some docu on how to create ubuntu installer images for "unsupported" devices
<marvin24> I have modified the omap netboot image already, and it seems to work
<marvin24> but that's more like a hack
<janimo> marvin24, nice, and 3.8 works just as well as our current kernel?
<janimo> marvin24, I am not sure about how community builds are run, ogra may know more
<janimo> I don't think there are easy tools, official images also contain a lot of per-target hacks both for builders and inside packages
<marvin24> janimo: so far everything fine, 3.8 already includes the tegra drm driver (lcd and hdmi output work)
<marvin24> so the patches are rather minimal
<janimo> marvin24, great. But too late for the 3.8 cycle?
<marvin24> it's a bit unfortune that there is so little docu about this
<janimo> marvin24, about image building?
<marvin24> janimo: in fact, bare 3.8 also works
<marvin24> janimo: yes
<marvin24> I guess there are many people who like to build images for their devices
<janimo> marvin24, indeed, it is a pity. The tools used for ubuntu images are not well documented either
<marvin24> well, there is build-live
<marvin24> I didn't dig too deep into the configuration
<ogra_> marvin24, we use livecd-rootfs to create the bits and then debian-cd and cdimage to assemble an image out of them
<janimo> marvin24, it even stops canonical employees from testing things fast locally, it does not only affect outside developers
<ogra_> everything sould be in public branches nowadays
<marvin24> ogra_: maybe someone could setup a page which describes the process somehow
<ogra_> (on launchpad, look for the cdimage team)
<marvin24> I kown I'm to lazy to read the source
<ogra_> marvin24, yes, someone should :)
<ogra_> (since years)
<janimo> it's not that it is not public (anymore at least) but not streamlined into one command that is easier than live-build
<ogra_> (livecd-rootfs is a wrapper for live-build btw)
<marvin24> ogra_: btw, https://gitorious.org/uboot-ac100/create_bootimage
<marvin24> builds an image which can be uploaded via tegrarcm
<ogra_> yeah, saw you talking about it on #ac100
<marvin24> no need to flash
<marvin24> starts raring netboot installer
<ogra_> mkimage ?
<ogra_> why dont you use text files for the config ?
<ogra_> (we do that everywhere lese nowadays)
<ogra_> *else
<ogra_> oh, a new florence release ...
<ogra_> something to test on the nexus7 :)
<ogra_> janimo, do you still work on the gyro sensor bits and camera support ?
<janimo> ogra_, I am still assigned those WIs so in principle yet. gyro first, webcam later
<ogra_> good
<janimo> for webcam I know there was some nvidia comments on the bugreport suggesting they too are looking into that
<ogra_> awesome
 * ogra_ finally has ureadahead working ... 
<ogra_> still struggling with plymouth
<ogra_> i got it booting without initrd ... but then plymouth crashes and mountall refuses to finish the fsck
<marvin24> ogra_: mkimage adds the u-boot header
<marvin24> ... which is not really required by u-boot anymore
<ogra_> marvin24, u-boot doesnt need that since over a year anymore, you can use uEvn.txt and preEnv.txt instead
<marvin24> I wonder why ubuntu still uses it (uImage, uInitrd)
<ogra_> because we have code that handles them generically across all u-boot images and nobody bothered to change anything there
<ogra_> panda is pretty much in maintenance mode ...
<ogra_> nexus7 and ac100 use fastboot ...
<ogra_> and the diferent server images we have ship with u-bppt on flash
<ogra_> *u-boot
<ogra_> (afaik at least, havent done much in the server area lately)
<marvin24> how is uEnv.txt loaded or embedded into the u-boot image?
<ogra_> the only actual improvement was the switch to txt files from  the silly boot.scr
<marvin24> is this omap u-boot specific?
<ogra_> no
<ogra_> upstream u-boot
 * marvin24 greps the u-boot source
<ogra_> should work on all setups that use upstream more or less
<ogra_> hmpf
<ogra_> so ureadahead speeds up booting noticeable ...
<ogra_> but only the part where we show a splash anyway ... the bits with black screen didnt get faster
<marvin24> ogra_: seems that uEnv.txt is loaded by a user defined script in some configs
<marvin24> tegra has only minimal config scripts for now
<ogra_> well, the functionallity to use it is upstream
<ogra_> you shouldnt need to do anything but enable it
<marvin24> ogra_: there is no "code" for this
<marvin24> it's just a macro in the board config
<ogra_> i thought there was
<marvin24> which calls "env load" from the u-boot prompt at the end
<marvin24> and then something must use these variables
<marvin24> I like the "source <some script>" aproach more
<marvin24> because it is more adaptable
<ogra_> but a nightmare to edit
<ogra_> boot.scr is one of the biggest complaints i had from users over the years
<ogra_> well, the need for post processing
<marvin24> yes, from a user perspective you are right
<marvin24> on the other hand, I first have to upstream some script which interprets the uEnv.txt to make use of it
<ogra_> k
<marvin24> http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/omap3_beagle.h
<marvin24> search for "bootenv"
<ogra_> i really thought that was an upstream addition thats usable everywhere now
<ogra_> i know there were a bunch of discussions on the cross-distro arm list
<ogra_> (to default to it for everything)
 * ogra_ curses 
<ogra_> ok, my kernel change didnt fix plymouth
<ogra_> :(
 * ogra_ sighs
<hrw> ogra_: nexus7 fight?
<ogra_> well, tegra fight
<ogra_> we have a similar prob on the ac100
<ogra_> i can fix it by running console-setup before plymouth runs
<ogra_> but i dont need to do that on any other arch and would likt to fix the root of the prob
<ogra_> especially since you force yourself to use an initrd when needing to run console-setup before
<ogra_> (and i'm trying to get rid of initrd completely for the installed nexus7)
<Tassadar> why, it speeds up the boot?
<ogra_> yes
<RaYmAn> so it actually partially boots a boot.img without a ramdisk on n7?
<ogra_> right
<RaYmAn> tf201's bootloader is buggy and needs a >0 byte ramdisk to actually boot kernel.
<ogra_> same for nx7
<RaYmAn> ah, ok
<ogra_> alternatively you can just disable the initrd support in the kernel
<ogra_> but since we use the initrd at install time and cant get around that, thats no option
<marvin24> is this a fastboot limitation?
<marvin24> RaYmAn: what about to upgrade to u-boot?
<ogra_> marvin24, rather abootimg i think
<marvin24> abootimg? that just creates a boot partition ...
<marvin24> fastboot has the size limit for the initrd
<marvin24> which comes from downstream AFAIK, so all tegra devices should have similar problems
<ogra_> well, abootimg doesnt let me add a obyte initrd
<ogra_> 0byte
<ogra_> no idea where the limitation lies :)
<marvin24> ogra_: use /dev/null as the initrd name
<marvin24> no joke
<ogra_> but from an enduser perspectice it starts at abootimg
<ogra_> oh, didnt try that
<lilstevie> with the tf201 it is actually the bootloader
<marvin24> ah, didn't know that
<RaYmAn> marvin24: on n7? Not really possible given it requires a signed bl.
<Tassadar> and it does not have nvflash yet - when you corrupt the bootloader, you have one nice brick
<marvin24> ah, rescue (rcm) mode als requires signed blob
<marvin24> otherwise you could just use tegrarcm
<marvin24> maybe someone should ask for the keys ...
<RaYmAn> It's per-device key
<marvin24> so they have a different "zero"-stage boot loader in each cpu?
 * marvin24 forgot how this is implemented in hw
<marvin24> or I just didn't read http://http.download.nvidia.com/tegra-public-appnotes/tegra-boot-flow.html
<marvin24> "The Tegra SoC supports various security modes. Some of these modes require the BCT, bootloader, and/or RCM protocol messages to be encrypted and/or signed with a potentially device-specific key. Details of these features are beyond the scope of this document.The Tegra SoC supports various security modes. Some of these modes require the BCT, bootloader, and/or RCM protocol messages to be encrypted and/or signed with a
<marvin24> potentially device-specific key. Details of these features are beyond the scope of this document."
<RaYmAn> doesn't that only handle the open case?
<RaYmAn> ah, right
<RaYmAn> but yeah, they are encrypted & signed with a device-specific Secure boot key (SBK)
<Tassadar> RaYmAn: so flashing/updating bootloader must be done by current active bootloader, since nothing else has the key?
<RaYmAn> Tassadar: that pretty much sums it up I guess
<Tassadar> that's dumb
<RaYmAn> (and no, you can't extract the key :P)
<Tassadar> yeah, it's all encrypted
<Tassadar> read that somewhere already
<ogra_> yeah, else nvflash would just work
<ogra_> or tegracrm
<lilstevie> Tassadar: why is that dumb? works quite well
<RaYmAn> in any case, fastboot won't let you flash a new bootloader because it requires that it's signed (by an RSA key)
<RaYmAn> (on n7)
<Tassadar> fasboot erase bootloader works pretty well too, unfortunatelly
<RaYmAn> so if google wanted, they could easily let us flash a signed uboot
<Tassadar> chmm, that is weird
<Tassadar> one CM developer managed to accidentally brick his n7 by "fastboot flash bootloader boot.img" Oo
<RaYmAn> that's not very likely
<RaYmAn> well, actually
<RaYmAn> hmm
<RaYmAn> there is *one* case where that could happen
<RaYmAn> It uses a rather specific way of signing bootloaders, so if the boot.img was signed the same way, it would flash
<Tassadar> it was probably just normal boot image
<RaYmAn> it refuses to flash those
<RaYmAn> I can't rule out a previous bootloader version might have allowed it
<Tassadar> anyway, I don't really get why do they even bother to lock it up like that
<RaYmAn> indeed
<RaYmAn> it's kind of pointless
<RaYmAn> I mean, you can partially understand it on phones - carrier lockin and stuff, lots of money involved
<RaYmAn> but on tablets? that's just silly!
<ogra_> probably just the same code
<ogra_> and someone being to lazy to special case it for tablets
<RaYmAn> mm
<RaYmAn> google actively enabled that extra layer of security.
<RaYmAn> It's entirely optional on tegra
<Tassadar> transformer's bootloader was encrypted too I think, Asus said that it was required to get like the DRM licences (?), and they released like "unlocked" version, which disabled google play movies or something like that
<RaYmAn> (as you know from ac100)
<Tassadar> if I'm not mistaken
<RaYmAn> the whole asus thing was one big misunderstanding. No one whining about it had any clue what it was about
<RaYmAn> but they did manage to convince asus to make an unlock, so no point in arguing ;)
<RaYmAn> the encryption/signing of the bootloader is a tegra SoC core feature. It's controlled by OTP fuses, so these fuses has to be actively burned to enable it
<Tassadar> well....nexus 7 has the same thing, shame that nobody cares since we can "unlock" ability to flash system/data/recovery
<RaYmAn> indeed.
 * ogra_ doesnt mind the bootloader ... but the GPT
 * Tassadar searches for GPT
<ogra_> the hardcoded partition table
<Tassadar> partition table!
<RaYmAn> yeah, that's a pain with the hardcoded offsets etc
<RaYmAn> (gpt_offset or something passed to kernel)
<ogra_> i would pretty much prefer we could just wipe the MMC completely and use it as single partition
<RaYmAn> yeah
<RaYmAn> I like how QC does it - just search for a partition iwth a specific UUID and load bootloader from there.
<marvin24> ac100 was never locked at all
<Tassadar> it was transformer prime
<Tassadar> the one with gps problems i believe
<RaYmAn> Tassadar: original transformer had exactly the same issues wrt bootloader.
<RaYmAn> well, except they didn't require signed boot.img & recovery.img for that.
<RaYmAn> But bootloader it self was encrypted & signed in the same way.
<Tassadar> yeah, here it is http://www.androidpolice.com/2012/01/03/you-spoke-asus-listened-an-unlock-tool-for-the-transformer-primes-bootloader-is-in-the-works/
<Tassadar> they say it is required because of DRM
<RaYmAn> the interesting part is that when you unlock e.g. N7, it leaves your DRM keys in tact and DRM still works.
<RaYmAn> whereas on TF Prime, they wipe the keys
<RaYmAn> So I suspect it's more of a misunderstanding in what is required.
<Tassadar> well, on n7 it does not unlock the bootloader itself
<lilstevie> explain?
<Tassadar> like the bootloader is still encrypted and must be signed
<Tassadar> if you want to flash another
<lilstevie> no different on the tf201
<lilstevie> the encrypted business is a one way deal
<Tassadar> :/
<Tassadar> I guess it would be complete surprise if the'd made up that stuff about DRM :)
<Tassadar> by the way, can't you play the movie via HDMI? Isn't the DRM pointless then?
<ogra_> HDMI has builtin DRM :)
<Tassadar> hah, okay)
<RaYmAn> Tassadar: look at HDCP
<Tassadar> "In September 2010, an HDCP master key [...] was released to the public"
<ogra_> sure, has the same status as libdvdcss
<Tassadar> so just another "DRM" to soothe the content publishers
<ogra_> you cant officially use or distribute it
<RaYmAn> does it even work for decrypting bluerays?
<RaYmAn> I mean, on a regular pc etc
<ogra_> HDCP is part of DRM ... else you could ... as you said above ... just copy the video stream
<RaYmAn> er, not blurays of course.
<RaYmAn> From what I heard, you need rather specialized hardware to actually take advantage of that key
<Tassadar> engadget says that "Hardware HDCP rippers like the HDfury2 and DVIMAGIC have been around" before that key was "released"
<Tassadar> it is probably not even used that much anyway, since ripping the blurays is clearly possible
<ogra_> http://www.iloveubuntu.net/mark-shuttleworth-video-demoes-ubuntu-phones-ces-2013
<ogra_> :D
<marvin24> yuhu - we'll get locked ubuntu
#ubuntu-arm 2013-01-09
<Ethernin> test
<SmallFry> You failed your test:P
<Ethernin> lol myes
<SmallFry> Myes?
<Ethernin> mmmmmmmmmmmmyesssssssssss
<SmallFry> Oh
<Ethernin> SmallFry, what do u use ubuntu-arm on?
<SmallFry> Nexus 7
<Ethernin> nice me too
<SmallFry> Multirom?
<Ethernin> any damn luck with the gestures or getting the user interface to be ah...more usable?
<Ethernin> I've just got the latest raring image on there, I've recompiled the kernel a couple times with a buddy to get it to do some extra stuff
<SmallFry> I installed kde,
<Ethernin> yeah i've tried litterally every desktop env
<Ethernin> kde was buggy as hell for me
<Ethernin> did u install just kde or plasma as well?
<SmallFry> Mine was a bit too
<SmallFry> Plasma won't show up if i install it via apt get
<Ethernin> yeah, i actually found xfce4 to be the most stable and customizable - problem was because it was xfce the touch screen wouldn't work for window titles/min/max/close
<SmallFry> Ugh
<Ethernin> i was bummed because xfce4 ran really well and really fast on the nexus, plus it's stable as hell
<Ethernin> it was just that ONE thing that was a pretty big deal
<Ethernin> lubuntu on the other hand worked pretty well
<Ethernin> lxde was OK, but also buggy as soon as u tried to resize ANYTHING
<Ethernin> I tried gnome class but it was virtually impossible to customize and not enough options for settings
<Ethernin> unity is pretty much unusable - soooo damn slow
<Ethernin> also had to stop a couple services right off the bat like avahi-daemon and cups
<Ethernin> SmallFry, the cool part was I was able to install just about any tool I wanted, but using that touchscreen is a nightmare
<SmallFry> I have been running vanilla
<SmallFry> I agree
<Ethernin> not the same experience as running android on the device...
<SmallFry> I'm such a Linus noob thougg
<SmallFry> Not at all
<Ethernin> I wish they would put a little more development into the interface and touch screen, plus the keyboard also needs some work
<Ethernin> but hey, i am happy they released it!
<Ethernin> I know youre working hard out there devs!
<SmallFry> Aye, had to put the on-screen keyboard button in the corner so I could get it up on unitys search
<Ethernin> yeah omg the thing is awefull for the most part
<Ethernin> i wish onboard actually was a little more concious of things running
<Ethernin> it's definitely getting better
<Ethernin> but it's not like in android where the keyboard is built into each app essentially
<Ethernin> so when you're using the terminal the keyboard doesnt block the text ect,
<SmallFry> Mhm
<SmallFry> The on-screen keyboard button actually isn't bad
<SmallFry> Just enabled it in the accessibility options
<Ethernin> yeah i love the button, just wish it was more application aware
<SmallFry> Yep
<raster> Ethernin:  keyboard isnt built into apps in android. but it is a standard SERVICE apps are aware of and they "request" either manualyl or as part of the toolkit
<Ethernin> raster, cool thanks for the info, so basically it's the apps that are aware of the keyboard, not the keyboard that is aware of the apps?
<raster> well its mostly the toolkjit
<Ethernin> raster, in ubuntu it's basically the other way around with onboard correct?
<raster> eg you place an entry "widget"
<raster> and when it is "focuseD" it asks for a kbd service
<Ethernin> riiiiiiiiiiiiiiiiiiiiiight
<raster> the kbd is in fact a separate window/app/process
<Ethernin> so with ubuntu
<raster> i think what ubuntu has done is recycle the input method framework to detect something needs input
<raster> *BUT*
<Ethernin> is it possible to get that same kind of functionality easily?
<raster> nmot everything is configured to use it
<Ethernin> right
<raster> or uses it "right"
<raster> and thus it doesnt work for all apps/all toolkits etc. in all cases
<Ethernin> yeah, my experience has been when it's been aware it basically triggers on input
<Ethernin> hmm,
<raster> most linux toolkits are pretty much unaware of vkbds at all
<raster> efl i think is a major exception
<Ethernin> raster, do you know of any terminals that are aware in such a way?
<raster> i dont know about qt
<Ethernin> efl?
<raster> gtk last i looked didnt really know anything specific
<Ethernin> ya
<raster> and xterm/rxvt etc. etc. just have no clue
<raster> they CAN use input methods
<Ethernin> hmm...yeah ive been trying to figure something out
<raster> but normally via xim (the old old old input method framework - your scim/uim/whatever will often have an xim bridge)
<Ethernin> i love the power of ubuntu and flexibility - but it's pretty hard to use with that touchscreen
<raster> tbh - i dont much care myself :)
<raster> 1. i use a toolkit that knows about vkbd's and input methods
<Ethernin> yeah yeah i hear that alllll the time :)
<raster> 2. i have a ui/desktop env that provides vkbd's built-in
<raster> 3. i work on both the toolkit and the wm/vkbd/desktop
<raster> so i can "make it work"
<Ethernin> cool
<raster> :)
<Ethernin> what toolkit?
<raster> whatever other things do... is of just "passing interest" to me. :)
<raster> efl
<Ethernin> awesome, checking it out!
<raster> as efl is what is used in tizen for mobile phones
<raster> it has.. support for this stuff
<Ethernin> reeeeeeeeallallllllly
<raster> touch figner controls/friendliness etc.
<Ethernin> that's interesting
<Ethernin> DUUUUDE
<Ethernin> THANK YOUS!
<raster> so just drag to scroll
<raster> (and it has momentum/bounces etc.)
<raster> well ok - its configurable
<Ethernin> ha!
<raster> it has "perconalities"
<raster> err  personalities
<Ethernin> enlightenment foundation libraries
<Ethernin> this is hilarious
<raster> configure in "standard" mode and u get a littrle scrollbar u drag as normal
<raster> and things kinda are desktop-y in the way they behave
<raster> copy & paste in entires etc.
<Ethernin> dude
<Ethernin> omg
<raster> if u switch to "mobile" mode
<Ethernin> this is EXACTLY what i have been looking for!
<raster> it swizzles some config values
<Ethernin> wicked!
<raster> and then finger drag scrolls, copy & paste/selections behave differently (finger-friendly)
<raster> etc.
<Ethernin> freakin awesome
<Ethernin> dude seriously thank you!
<raster> so basically an app can work on both a desktop (mouse+kbd) setup and a touch setup
<raster> just by swizzling "system config vlaues"
<raster> system confgi also controls scaling ANd sizing of ui elements
<raster> ie figner size forces any elemnt u are to "click/touch/press"
<SmallFry> Its just an apt get?
<raster> and forces it to be a bigger size
<SmallFry> Apt-get efl?
<raster> ie.. be a "finger in size" so its easy to hit with a finger
<Ethernin> wow they even got the domain name "enlightenment.org"
<raster> so if on a tocuh ui - just scale up the finger size and its easy to use
<raster> if on mouse/kbd - dial down finger size and elemtns size less "fatty" to reflect that a mouse is far more accurate in hitting things
<SmallFry> Is it just apt get efl?
<raster> it'll dynamically adapt
<raster> u'll probably need to find a ppa
<raster> and it isnt called "efl" in packages
<Ethernin> raster, omg dude this is exactly what i've been trying to find, yeah so do you have to compile from source or is it in the repos?
<raster> its split into about a dozen libraries
<Ethernin> ok
<raster> Ethernin: :)
<Ethernin> i've been looking at multitouch and utouch for gestures ect, but this seems like THE TICKET!!!
<Ethernin> raster, ^_^
<SmallFry> What's a Ppa...
<raster> https://launchpad.net/~hannes-janetzek/+archive/enlightenment-svn
<Ethernin> wow that was quick!
<raster> Ethernin:  also efl supports multitouch
<raster> it happens to work out of the box on my n7
<raster> tho i did compile efl myself
<Ethernin> OMFG
<Ethernin> HURRRAY!!!!
<raster> and i made sure to enable the xi2.2 support
<raster> elementary has a multitouch test
<Ethernin> what's the xi2.2 support?
<raster> just stick multiple fingers on there
<raster> if u get multiple "target points" ttracking all your figners
<Ethernin> yeah i saw that, the 3 finger touch
<raster> then its working
<raster> it works for me
<Ethernin> dude
<Ethernin> youre my savior man!
<raster> there are other gesture tests
<Ethernin> "my own personal jesus christ"
<raster> eg pinch-to-zoom stuff
<Ethernin> "mesculin, it's the only way to fly :)"
<raster> theres one test that lets u zoom+rotsate a photo with momentum as u slide it around
<Ethernin> this is amazing
<Ethernin> i knew there was a way....
<raster> some widgets support multitouch out of the box
<raster> eg the photocam widget (for displaying big megabgapixel camera photos)
<raster> pinch to zoom should work there
<Ethernin> yeah, u can triple tap to move windows, but it's flaky at best out of the box
<raster> as with the map widget )(can do openstreetmaps and otehr mappign service stuff)
<Ethernin> dude i can't tell u how psyched i am now!!!!!!!!!!!!!!!!!!
<Ethernin> i wanted the pinch zoom bad too...
<raster> xi2.2 == Xinput 2.,2
<raster> err xinput 2.2
<raster> as of xinput v 2.2 full touch support was added to the xinput layer
<raster> "properly"
<raster> its supported in efl
<Ethernin> riiiight, so there's a conf file for that where you can add custom gestures right?
<raster> mostly due to the fact it has mpx support already for xi2.0
<raster> and that it is used in tizen which right now is heavily mobile/touch focused and thus gets the attention and work
<SmallFry> Ethernin
<raster> umm no
<raster> no conf file for gestures
<raster> gestures are recognised in code
<raster> they arent "draw symbol x"
<raster> so it isnt a series of points to match
<SmallFry> If you get this stuff compiled, shoot it my way would you?
<Ethernin> ah
<raster> gestures are dynamically tracked
<Ethernin> SmallFry, sure thing, I;ll try it out and give u my steps if i get it working!
<raster> and literallyu if u write an app and code to handle specific gestures - u register for a gestrure event
<Ethernin> interesting
<raster> and then AS the gestrues are recognized u are told what is recognized and parameters for it
<raster> eg how much you just zoomed with a pinch
<SmallFry> Sure:) shoot me a PM anytime
<raster> etc.
<Ethernin> ok right on
<Ethernin> raster man thanks for the clarification, VERY HELPFULL
<raster> so its not just "oh he drew a circle"
<Ethernin> :P
<raster> or "he drew a Z"
<raster> its more the swipe/pinch/ etc. style gestures
<raster> with 1, 2 or 3 fingers etc.
<raster> see gestture layer test in elementary_Test
<raster> it shows u gestures i knows of and lights up the ones it recognizes
<Ethernin> ok that makes sense
<raster> imho recognizing if u "drew a Z" is a whole different class of thing
<Ethernin> oh man, ok going to try and get this working!
<raster> ie its shape recognition basically
<Ethernin> coooool
<raster> recognizing some shape u drew
<raster> anyway
<raster> just fyi :)
<raster> play with it as u like
<Ethernin> i gotta run but ill be back, raster thanks again man, SmallFry I'll be back trying to get this working on my N7
<SmallFry> Ok
<Ethernin> oh hellllllllllllllllllllllllllls yeah!
<raster> #e if u want to ask
<raster> as u'll get more answers there
<SmallFry> Thanks
<Ethernin> #e?
<raster> i should have made some videos
<raster> channel
<raster> #e
<Ethernin> k
<Ethernin> wicked
<Ethernin> dude seriously thanks much
<raster> see the enlightenment.org website
<Ethernin> ill be on in a while to mess with this stuff!
<raster> info on "contacting" etc.
<raster> mailing lists
<raster> irc
<Ethernin> yeah im checking it out for sutre!
<raster> etc.
<Ethernin> so dope
<Ethernin> later boys!
<raster> it also is a lot less heavy than unity
<Ethernin> thank the lords
<Ethernin> so wait, is it a full desktop env????
<raster> after switching to e17 i managed to wipe off about 200-300m of mem usage compared to unity on my n7
<raster> yes
<Ethernin> holy crap it is!!!
<raster> it also is a full desktop env
<Ethernin> DAMN
<raster> with compositing
<raster> both gl and software
<Ethernin> dude this is INSANE!
<Ethernin> omg, i love u
<raster> software comp is fast enough to be usable on my old penitum-m @ 600mhz
<Ethernin> hahahahahaa
<raster> no gpu there
<Ethernin> YESSSSSSSSSSSSSSSSSSSSSSSS
<raster> not needed
<raster> sure - not silky smooth at all times
<Ethernin> ill be back, thanks again!
<raster> but usable
<Ethernin> --out
<raster> gl accel of course works
<raster> opengl-es2
<raster> etc.
<xenome> is there an easy way to change the uboot splash screen with two penguins to something else?  Must I recompile uboot to make that work?
<infinity> xenome: That's not uboot, it's the kernel.
<xenome> ah, is there a way to change that w/o having to rebuild the kernel?
<xenome> does that get pulled from the initramfs?
<lilstevie> xenome: it is part of the kernel
<lilstevie> and your options are, leave as is, or turn them off
<xenome> how can I turn them off? quiet?
<lilstevie> recompile the kernel
<xenome> oh, ok so no boot option
<xenome> bummer
<xenome> if I'm going to recompile, should I get the ubuntu source for my kernel or get adventurous and try mainline
<xenome> i suppose I'm in a pickle because I need to use the TI kernel for maximum driver support
<infinity> xenome: We actually remove the penguins on our master kernels, I believe.  You could file a bug asking for that patch to be included in linux-ti-omap4 as well, if you're using Ubuntu's omap4 kernels.
<infinity> (At least, I haven't seen a penguin on my x86 framebuffer in years, so I assume we're disabling it... Or we just draw over over it so fast I don't notice)
<reisei> Hi, all! I want to ask you about installing ubuntu on the Nexus 7.. Can I install there my own image of ubuntu? Without the installation progress.
<Jef91> Does anyone know what is the full list of packages that contain all the 3d drivers for the nexus 7?
<lilstevie> nvidia-tegra3?
<reisei> what should contain image file for nexus 7? rootfs?
<rigved> hello everyone
<rigved> I have installed ubuntu on my Nexus 7 32 GB. But it shows that disk space for "/" is only 6 GB. Have I installed the wrong image? I have used the Desktop Installer to install the image automatically to my Nexus 7.
<ogra_> no, you havent, we dont offer specific images for the differently sized devices yet
<ogra_> so currently the image for 8G is the one used on all devices
<rigved> ogra_: oh. ok. is there any way to use the remaining space? maybe by creating a new partition?
<ogra_> you could repackage the image before flashing, but there is a high risk that fastboot will corrupt it while flashing
<brendand> xnox, ogra_ - is there a bug number for ubiquity not accepting text entry on the user details screen?
<ogra_> xnox, bug 1093050
<hrw> ogra_: can't you repartition emmc?
<ubot2> Launchpad bug 1093050 in ubuntu-nexus7 "OnBoard doesn't work on text boxes during initial setup" [Medium,Incomplete] https://launchpad.net/bugs/1093050
<ogra_> hrw, nope
<hrw> ogra_: but that's still emmc?
<ogra_> hrw, the GPT is hardcoded in the bootloader, the bootloader is a signed blob we cant replace
<hrw> o fsck
<hrw> ogra_: fsresize possible?
<ogra_> you can resize them, but then you get massive FS errors
<brendand> ogra_, for me onboard appears but typing does nothing
<ogra_> i tried that when rolling the first images
<ogra_> brendand, right, a reboot should fix that
<ogra_> there is some kind of race on the first boot or so
<ogra_> which doesnt seem to show up on subsequent boots into the installer
<brendand> ogra_, ah strange
<ogra_> well, metacity worked fine, the bug started showing with the switch to compiz
<brendand> lovely compiz
<ogra_> xnox, seen that ? https://bugzilla.redhat.com/show_bug.cgi?id=859373 ... http://lists.fedoraproject.org/pipermail/package-announce/2012-November/090998.html ?
<ubot2> bugzilla.redhat.com bug 859373 in ntfs-3g "Danger in dual booting Windows 8 and Linux" [High,Closed: errata]
<ogra_> seems ntfs3g needs a fix
<rigved> ogra_: ok thanks
<rigved> btw, i did experience the same problem with ubiquity nt accepting text entry in the oem setup screen
<xnox> ogra_: yes, we did add a similar erratra for wubi & quantal. I think we might be recent enough as we do bail out at mounting windows8 (hence the complaints)
<rigved> i was able to reproduce the error
<ogra_> xnox, ah, k, i just saw a news article from today that claimed we dont have the fix in ubuntu and debian
<xnox> ogra_: not sure now, I'll double check and cherry pick as well if we are missing that bit.
<xnox> ogra_: i'll ping you when I check.
<rigved> just selecting "Show Password" in the wifi setup screen would bring the problem. after selecting "Show Password", onscreen would not work. reboot was needed.
<Rjs> would it be possible to use e.g. LVM on the partition to split it into one filesystem for the original image and another that is created on the first boot or so? hmm, or could the ubuntu installer load itself into RAM and create the actual file system while installing instead of having a premade fs image? (just speculating here...)
<ogra_> xnox, the last upload was in sep. 2012 ... i doubt it has the fix
<xnox> yeah.
<ogra_> heh, seems FAT has the same issue on win8 ... but no way to determine if the FS is unclean or not ...
<ogra_> Rjs, how would having the installer in ram help ?
<ogra_> ... if you cant change the partitioning :)
<ogra_> Rjs, we were pondering LVM, but thats kind of a hack
<Rjs> ogra_: then the installer could create a full-size filesystem from scratch on the actual device, so it would just use whatever size partition the device has?
<ogra_> (vs properly having a single partition across the whole MMC)
<ogra_> Rjs, see above, hardcoded partition table
<ogra_> you cant really change it
<Rjs> ogra_: hmm, does it have a hardcoded 8gb partition on all of the devices?
<ogra_> no
<ogra_> it has a 6G partition as "userdata" on the 8G device
<ogra_> all other devices have bigger userdata partitions
<ogra_> 6G is the smalles common denominator across all devices
<Rjs> ogra_: so if the installer loaded itself into RAM, could it then use mkfs to create the filesystem on the userdata partition (and, say, extract a tar to it to have the initial contents of the file system)?
<Rjs> ogra_: then the mkfs on the installer could select the filesystem size based on the size of th userdata partition on the actual device that it is currently installing to?
<ogra_> no
<ogra_> partitions formatted from the initrd (or wherever you sit in ram) end up with a broken filesystem that loses data over time
<ogra_> you filesystem has to be created by the android mkfs
<ogra_> (we spent about a week to come up with the cleanest way that doesnt eat your data when we designed the image type)
<ogra_> what you can do, and what the usb-creator installation will do, is repacking the image before flashing top the right size using the android-fstools
<Rjs> ogra_: oh, sorry, I didn't know that... is it because of some sort of android kernel oddity? (the userdata partition is not just a standard block device where the OS can write whatever data it wants to?)
<ogra_> it is because of the GPT partition table that is hardcoded in the bootloader
<ogra_> it is hard to tell what exactly is the issue sinbce the whole bootloader is a big binary blob
<ogra_> and you cant replace it
<Rjs> ogra_: hmm, but after the kernel gets loaded, /dev/mmcblk0p3 (or whatever number the userdata partition has) isn't just a block device that you could access from the initrd to create whatever filesystem you want there?
<Rjs> or does the bootloader need something special written on the userdata partition? (so you couldn't for example use a completely different filesystem type for it?)
<ogra_> it is, but filesystems created with standard fs tools fail
<ogra_> feel free to research it :)
<Rjs> hmm, I could try if/when I get the time :) (I just recently bought a nexus7 for testing, but haven't yet had time to install anything on it)
<ogra_> working images can be created using the make_ext4fs tool from android-fsutils ... the source code is there, you could research what the mkfs dpoes differently from a normal mkfs :)
<ogra_> we used to use the "format from ram" approach in the preinstalled pandaboard images we had earlier
<Rjs> ogra_: hmm, ok... maybe I'll try to look into it if I get the time and energy (probably not in a while)... thanks for the information :)
<marvin24> jay, https://launchpad.net/~marvin24/+archive/tegrarcm
 * marvin24 celebrates his first package
 * ogra_ applauds 
<ogra_> congrats !
<marvin24> ogra_: now tell me how to build it for different ubuntu releases ;-)
<ogra_> you need to change the changelog ...
<ogra_> and re-upload for each release (after rolling a fresh source package indeed)
<Tassadar> cg :) does whoopsie (or how is that "Error occured, send report" thing called) produce logs?
<ogra_> apport does, whoopsie just commits them
<marvin24> ogra_: ok, I hoped that would be more easy using some launchpad interface
<ogra_> in /var/crash/
<ogra_> there might be an easy way i dont use :)
<Tassadar> because something crashes on my n7, so that this window shows up pretty frequently
 * Tassadar is looking to /var/crash
<ogra_> the .crasdh files in /var/crash have pretty recognizable names
<Tassadar> yeah
<Tassadar> dbus a cups
<Tassadar> *and
<Tassadar> cups' error log says that some ssl keys are missing http://pastebin.com/rQfak24W Oo
<Tassadar> seems that "make-ssl-cert generate-default-snakeoil" in /etc/ssl/certs fixed it
<Tassadar> can somebody confirm that this is happens for all n7's? I mean the "System error occured" window with "report" option?
<ogra_> if something crashes it should happen on all n7's
<ogra_> happens on your desktop too :)
<Tassadar> well i am multi-booting it, it _may_ be because of that, but I don't think so
<Tassadar> anyway, if I won't find bug report about this, I'll create one
<ogra_> just click report :)
<Tassadar> gksudo
<Tassadar> plus, when I managed to somehow type my password in, the report process crashes :x
<Tassadar> well, not crashes, "fails" or something
<ogra_> gksudo ?
<ogra_> i dont unbderstand
<Tassadar> unable to enter password to gksudo
<ogra_> gksudo shouldnt be used by anything on the desktop
<Tassadar> it like "disables" rest of the screen, including the keyboard
<ogra_> if it pops up *anywhere* thats a bug
<ogra_> apps needing admin privs need to use pkexec
<ogra_> which doesnt have such issues
<Tassadar> well, I am not sure it is gksudo, i just can't enter anything and it is exatly like https://bugs.launchpad.net/ubuntu-nexus7/+bug/421660
<ubot2> Launchpad bug 421660 in ubuntu-defaults-nexus7 (Ubuntu) "gksu's and gksudo's modal password prompt prevents OnBoard's virtual keyboard input, causing accessibility issues" [High,New]
<ogra_> Tassadar, https://bugs.launchpad.net/ubuntu-nexus7/+bug/421660/comments/10
<Tassadar> okay
<ogra_> so if its actually gksudo it would be good to find out which component uses it and file a bug against it
<wookey> OK. sbuild --host arm64 now works with raring + my raring-bootstrap. :-) I'll run a build and see how much breakage we have left
<marvin24> ogra_: seems changing the distro in changelog is not enough, do I also need to bump the package version?
<ogra_> hmm. you shouldnt need to
<marvin24> dput says: "Package has already been uploaded to ppa on ppa.launchpad.net"
<marvin24> the source.changes shows different distributions
<ogra_> ypou need to remove the local .upload file :)
<ogra_> xnox, so ayan would like to work on the usb-creator installation bits ...
<xnox> \o/ ok =)
<ogra_> :)
<ogra_> ayan, if you run into any issues dont hesitate to ask here ;)
<xnox> I can help. I should make usb-creator trunk to be usable. But then new bits can be added.
<ayan> ogra_: will do.
<xnox> ayan: it's fairly nice architecture: sepearate frontends & backends. I guess nexus7 images should be as a new backend & then the UI can be hooked up to it.
<xnox> which reminds me about udisks2 port
<ayan> xnox: ya, maybe this is a good time to port usb-creator to udisks2?
<xnox> it's long overdue. usb-creator is the last package to use udisks1 on the desktop cd, everything else was ported already.
 * ayan nods.
<ayan> i took a brief look at it a while ago.
<ayan> if you don't mind, i can take a stab at it today.
<Jef91> For the Ubuntu nexus7 image, to suspend the device does it just use pm-utils, pm-suspend function or something custom for the device?
<morphis> Jef91: it should use pm-utils as far as I know the N7 provides the common kernel interfaces for suspend
<Jef91> kk morphis thanks
<Jef91> hrmm I have audio working at startup on my nexus 7
<Jef91> without doing a suspend/resume dance
<Jef91> now I just need to figure out how I accomplished this
<Ethernin> nice yer here too
<Ethernin> lol
<Ethernin> Hey you ubuntu-arm wizard devs, trying to install Jef91 custom image he made (dope btw u should check it out) and having the same issue trying to install the old image on a 32gb with 3g Nexus7
<ayan> afk.
<wbf> hello!
<wbf> I've been having this error: http://paste.ubuntu.com/1514650/
<wbf> and I've been wondering how to fix it.
<wbf> trying to compile the pegasus driver for ARM
#ubuntu-arm 2013-01-10
<voltagex_> Hi, is the source for kexec-hardboot anywhere?
<voltagex_> Ah, found it
<gdane> is someone work with old armv5?
<ogra_> achiang, poke
<wookey> cjwatson: what was that URL you showed me yesterday with cross status summary. Can;t find it now...
<wookey> only the older/more detailed: http://people.canonical.com/~cjwatson/cross/armhf/raring/
<cjwatson> wookey: https://wiki.ubuntu.com/CrossBuilding/BuilddChroot perhaps?
<wookey> ah yes - cheers. too much internet these days :-)
<marvin24> ogra_: https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-tegra/+bug/1085266 and https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-tegra/+bug/1085266 btw
<ubot2`> Launchpad bug 1085266 in nvidia-graphics-drivers-tegra (Ubuntu) "nvidia-graphics-driver-tegra needs developer package" [Undecided,New]
<marvin24> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-tegra/+bug/1085452 I mean
<ubot2`> Launchpad bug 1085452 in nvidia-graphics-drivers-tegra (Ubuntu) "please provide an openmax package for tegra SoCs" [Undecided,New]
<ogra_> well, i have to update it once nvidia privides the driver for the new xorg anyway
<ogra_> feel free to assign to me
<ogra_> but i have to wait for the new drivers
<ogra_> (we're switching to ABI 14 soon afaik)
<marvin24> 14? this is one and a half year old!
<marvin24> 16r2 is current
<marvin24> or do you mean xorg abi
<marvin24> ah, must be
<ogra_> yeah
<ogra_> heh
<rigved> hi everyone.
<rigved> i was thinking of trying to rebuild the raring build to resize the image for my 32 GB tablet.
<rigved> till now, i have found this: http://www.mattfischer.com/blog/?p=285
<rigved> but it says that the process has changed for 13.04
<rigved> could anyone help me with the changed process?
<Tassadar> well, the process is more or less the same, but the 32gb image will not flash because it is too big
<Tassadar> do you have some custom recovery installed on your n7? (if you don't know what that is, you don't have it)
<achiang> ogra_: hi
<ogra_> achiang, any idea what we plan wrt the weekly n7 meetings ?
<ogra_> i was asked by a few people now if we stopped working on n7 because there are no status infos anymore :)
<ogra_> rigved, install android-fsutils, unpack the image with smig3img, loop mount it, copy the tarball to a temporary dir and use make_ext4fs with your preferred size to create a new rootfs image
<achiang> ogra_: we should do them again
<achiang> ogra_: i've just been maxed out lately
<ogra_> *simg2img
<ogra_> achiang, k, just wanted to know the plans, thx
<rigved> Tassadar: no, i do not have any custom recovery installed (i do not know what that means ;) )
<Tassadar> okay, then do what ogra says :)
<rigved> ogra_: ok. i am following your instructions now.
<rigved> Tassadar, ogra_: thanks. will revert back with status.
<jpastore> hola, i have a beaglebone running ubuntu arm 12.04 and I'm getting an error trying to install or update packages via apt-get. followed some howto's on trying to resolve it to no avail
<ogra_> can you pastebin the error ?
<jpastore> sure 1 sec
<jpastore> ogra_, http://pastebin.com/i3cypqxY
<ogra_> sudo cp /var/backups/dpkg.status.0 /var/lib/dpkg/status
<ogra_> and trz again
<ogra_> *try
<ogra_> also check dmesg for filesystem errors etc, that database doesnt break on its own usually
<jpastore> ok
<jpastore> ogra_, same fail
<ogra_> hmm, did you take a look at /var/lib/dpkg/status ?
<ogra_> its a text file
<jpastore> ogra_, yea but it looks like a tab delimited file that i can't make sense of...
<jpastore> it look structured and ok...consistent...but i don't know what the values mean and their relevance
<ogra_> it should just be package descriptions plus their status
<ogra_> you can try moving the file out of the way for a test (and touch an empty one in place)
<jpastore> ogra_, ok i think I tried this in a how to, but let me try again following your instructions...i can't talk to a howto =)
<ogra_> heh
<jpastore> ogra_, hmm...update ran with no error or updates...
<jpastore> going to try and install some stuff...thanks for the help. i appreciate it. have a good day!
<plars> xnox, ogra_: back before the holidays, we were discussing how to preseed the install on nexus7. Any ideas on this? nothing I've tried so far has worked.
<xnox> plars: well on the kde active blog, they use adb to change kernel command line. I wonder if we can abuse that for preseeding nexus7
<xnox> but I still didn't check if end-user oem-config can at all be preseeded or not.
<plars> xnox: I've slept since then, but I think I tried setting a few options that way without any luck
<plars> xnox: then I tried copying the image to the device before starting the first boot, and I also tried inserting it in the initrd.  Neither worked for me so far but it's entirely possible that I'm just missing something
<plars> xnox: You had mentioned that you were going to check that, and I was wanting to get some confirmation that I wasn't trying something here that simply isn't possible
<xnox> ah. that's what happened.
<xnox> Ok. I have one more oem-config bug to check, I guess my next install will be oem-config.
<jodh`> ogra_: is ureadahead on arm affected by bug 1085766?
<ubot2`> Launchpad bug 1085766 in ureadahead (Ubuntu) "/var/log/upstart/ureadahead.log contains garbage" [Undecided,Confirmed] https://launchpad.net/bugs/1085766
<rigved> Tassadar: ok. you are right. it seems that the 27G image is not being flashed. been waiting for too long.
<Tassadar> what size is the image? like the .img file?
<rigved> i was reading up on the multi-boot method. it involves a custom recovery. why did you ask me about it earlier? will i be able to flash, say a 13G image on to it using that method?
<Tassadar> well, you can access the data partition from there, so you could just copy the root.tar.gz from USB drive to /data
<rigved> Tassadar: 706M
<Tassadar> yeah, that is a bit too much
<rigved> Tassadar: ok
<Tassadar> you wanna try to install it using the recovery?
<rigved> i could try. has anyone tried it before?
<rigved> did it work?
<Tassadar> i would guess not, but well, it is just copying one file
<Tassadar> you don't even have to install the recovery, just boot it using "fastboot boot"
<jpastore> is it a problem to install php5 on a beaglebone?
<rigved> Tassadar: ok. please correct me if i got this wrong. install the 8G version manually; before booting into ubuntu the first time, boot into fastboot boot; copy the new root.tar.gz over to the /data partition; then boot into ubuntu.
<Tassadar> well, you need to make the /data 27gb big, and you can't really do that without loosing data, so I would recomend flashing factory android image (that will also properly format /data to 27gb
<Tassadar> )
<Tassadar> then wiping /data, and copying rootfs.tar.gz in there
<Tassadar> (if your /data is not properly formated already, that is, I dunno what that failed fastboot did, maybe it did not do anything)
<rigved> Tassadar: ok. i am trying that now.
<jpastore> so I'm trying to setup a webserver on a beaglebone. started by apt-get install php5, figured that would give me everything i needed or get me close. apt-get failed and recommended: apt-get -f install...which also failed. pastebin: http://pastebin.com/VxajDrkQ
<jpastore> any ideas on how to resolve?
<Tassadar> did you do apt-get update?
<jpastore> i did
<Tassadar> it says "E: Cannot get debconf version. Is debconf installed?", did you notice that?
<jpastore> checking
<jpastore> aptitude search debconf shows pi next to it. i means installed correct? i'm used to the gui on my laptop
<Tassadar> I don't really know, but trying "apt-get install debconf" would surely do no harm
<jpastore> Tassadar, installing debconf is failing via apt-get and aptitude...here's the pastebin: http://pastebin.com/6PQYpYTu
<Tassadar> it kinda looks like there is something broken in there, it looks kinda weird that "apt-utils", "dpkg" and "coreutils" are not installed yet
<jpastore> i think older versions are installed
<jpastore> and it's not updating
<jpastore> maybe I should backup the image and do a distribtion upgrade?
<Tassadar> wait, your dpkg status file was broken, wasn't it?
<jpastore> I think so
<Tassadar> how did you fix it?
<jpastore> I'm trying: aptitude -f install dpkg
<jpastore> it's not
<jpastore> it's failing on libc6 support and multiarch-support
<Tassadar> I dunno, it to me it _looks_ like something is terribly messed up, if that status file is not correct, it _might_ be the cause
<jpastore> Tassadar, I moved the status and touched a new one because i was getting errors saying the status file could not be parsed
<jpastore> I was then able to do an apt-get update
<jpastore> I then later tried to install php5...and now I'm stuck
<Tassadar> can you check what is in that status file? Like did it re-fill that file or is it just empty?
<jpastore> it repopulated
<jpastore> it's about 3600 bytes...whereas the backup one was over 400k
<Tassadar> maybe it can't be just repopulated like that
<jpastore> maybe...but I was going on a suggestion from ogra_. it seemed to allow the apt-get update to work but I'm not able to install basic stuf like tzdata
<jpastore> I wish there was a repair all problems option....
<Tassadar> try to ls /var/backup, there might be another backup of dpkg.status
<jpastore> ok... 1 sec
<jpastore> there's a dkph.status.0 that's 435k like the other status file I backed up
<jpastore> Tassadar, I got these: /var/backups/dpkg.status.0  /var/backups/dpkg.status.1.gz  /var/backups/dpkg.status.2.gz
<Tassadar> well, try to use it, maybe that one is okay
<jpastore> ok
<jpastore> just copy that file to /var/lib/dpkg/status and run apt-get update?
<jpastore> no it's unable to be parsed
<Tassadar> yeah
<jpastore> trying to regen the file
<jpastore> this is like tryign to fix a looping cpan failure...
<Tassadar> yeah, dpkg/status is rather fragile :/ why did it break anyway?
<Tassadar> like, isn't the sdcard corrupted or something?
<jpastore> Tassadar, it's been broken. I got an image installer for the beagle bone ...no love. I was told not enough ram to handle updates but i find that hard to believe. after going through the steps to resolve I seem better off but not funcitoning and don't know what to do
<jpastore> not sure the sd card is corrupt...possible but unlikely. it's a spare 32g I had in a phone
<Tassadar> I don't really know anything about the beagleboard, somebody who does would probably be more helpful
<jpastore> appreciated.
<jpastore> thanks for the effort. when I go over to #beagle* they give me crap for installing ubuntu instead of solving the problem. so I'm at a loss for where to go..
<Tassadar> :D
<jpastore> Tassadar, what about downloading these packages and manually installing them. like debconf and perl-base
<Tassadar> well, there is no harm in trying, but I am inclined to think that dpkg status file can't be even fixed
<jpastore> hmmm...
<jpastore> maybe I should backup this image and try a fresh 12.10 image. I had problems with that too...but maybe the status fix that I did in 12.04 will make it work.
<Tassadar> yeah, flashing fresh image would probably be the best
<jpastore> yea I think I'm going to try that later...
<jpastore> thanks again
<camm`> anyone here able to field a reloc question?
<Tassadar> Jef91: you maintain BohdiLinux image for nexus 7, right?
<Jef91> Yes Sir Tassadar
<Ethernin> Hey Jef91 do u have a package list for the enlightenment stuff you installed?  I'd love to have this setup on top of ubuntu as the desktop environment and am wondering what else i need besides e17
<Tassadar> you realeased new one yesterday, will apt-get upgrade update my current installation? Or are these just images without proper repositories?
<Jef91> Tassadar: most of my stuff is just manually setup at the moment
<Jef91> Not in package form
<Jef91> So, tl/dr you need to reflash
<Tassadar> okay, thanks
<Jef91> Ethernin: I have my own custom package set
<Jef91> Ubuntu E17 packages are old and awkward
<Ethernin> Jef91, word, is the list on your website at all?
<Jef91> Ethernin: packages.bodhilinux.com has our repo list in html form
<Jef91> Lots of stuff on there.
<Tassadar> btw, I was kinda surprised to see how fast e17 is on n7, both unity and plasma are struggling with 3D acceleration I guess :)
<Jef91> ha
<Jef91> Tassadar: e17 is fast on everything
<Jef91> modern desktops need to learn from it
<Jef91> and stop bloating their shit
<Ethernin> aweomse thanks Jef91
<Jef91> Ethernin: keep in mind the ARMHF packages there are built for Debian Wheezy
<Jef91> YMMV on other platforms
<wbf> Hello!
<wbf> I have succeeded in installing ubuntu on the UG802
<wbf> the only problem is..
<wbf> the belkin usb card it doesn't work
<wbf> as in the F5D5050
<ubuntubhoy> is it a known issue with linux for that card ?
<wbf> no 5 people said the pegasus driver works just fine
<wbf> but I cannto compile it successfully for arm
<ubuntubhoy> hmm
<ubuntubhoy> what is the F number on the card
<ubuntubhoy> iirc there are dif versions of that chip
<ubuntubhoy> can't remember if they all work
<wbf> F5D5050
<ubuntubhoy> but the pegasus driver wont compile
<wbf> yep
<ubuntubhoy> what errors you getting
<wbf> 1 second
<wbf> http://paste.ubuntu.com/1518086/
<wbf> ubuntubhoy,  PS: got all drivers to work via â¨ (commandline) so far and got the video to work, it's now a working desktop :D
<wbf> ubuntubhoy, except the belkin
<ubuntubhoy> That's not bad going in itself
<wbf> can you help me through? can you compile the drivers for arm and send them to me?
<wbf> ubuntubhoy, Are you still there?
<ubuntubhoy> sorry mate was working
<ubuntubhoy> also, I am not able to compile anything here
<wbf> oh
<ubuntubhoy> but I was having a look about to see if I could find the cause
<ubuntubhoy> nothing yet
<ubuntubhoy> sorry
<wbf> Hello?
<wbf> Anyone here?
#ubuntu-arm 2013-01-11
<rigved> hi everyone.
<ogra_> jodh, http://paste.ubuntu.com/1519386/ no issues with my ureadahead logs
<rigved> i want to use the full space on my nexus 7 32GB in raring. but due to size limitation of flashing userdata, i am unable to do so using the 27G userdata image. Tasssadar yesterday suggested that i should just copy the root.tar.gz file to /data. can anyone tell me how to do that?
<jodh> ogra_: thanks for info.
<ogra_> jodh, note that this was only fixed very recently by a kernel patch and config change for the nxus7
<ogra_> (last week)
<jodh> ogra_: what was happening before?
<ogra_> ureadahead exiting, the sysfs files it wants to read were missing
 * ogra_ got the famous "exited with status 5" message on every boot :)
<jodh> ogra_: ok, thanks.
<ogra_> i dont think it is related in any way to your bug
<aladdin> hello everyone
<aladdin> any update about https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1084852 ?
<ubot2`> Launchpad bug 1084852 in chromium-browser (Ubuntu) "Chromium still tries to enable NEON on arm* builds when told not to" [High,In progress]
<aladdin> no update since one month :(
<aladdin> showstopper to release new version of chromium
#ubuntu-arm 2013-01-12
<cukkimo> Hello!
<cukkimo> I've ran into some problems with my pandaboard when running ubuntu-arm 12.04. Random green pixel "noise" in the screen as well with vertical lines and monitor going out of range when under graphical load
<cukkimo> Jockey cant install proprietary drivers
<cukkimo> I've done dist-upgrade with tiomap/release repo and ubuntu arm repos, yet still the problem persists
<cukkimo_> Anyone?
<Tassadar> nah, just 150 people idling)
<cukkimo_> As I did kinda suspect that...  :D
<cukkimo_> WARNING: /sys/module/omapdrm_pvr/drivers does not exist, cannot rebind omapdrm_pvr driver
<cukkimo_> Might this be the problem, it's from the jockey.log
<cukkimo> What version of ubuntu is more likely to run perfectly on pandaboard? Im thinkin of installin ubuntu-core 12.10 as it could be more advanced for ARM devices since the new launch. Am I even remotely on the right path?
<mjrosenb> well, this is strange.  I'm looking at the directions for building a raspberry pi cross compiler
<mjrosenb> and I don't see it doing anything different from a normal cross compiler build.
<SmallFry> why is tha strage?
<SmallFry> it's just a cross compiler
<mjrosenb> because the standard cross compiler doesn't work.
<SmallFry> oh
<SmallFry> herm
<SmallFry> idk then, sorry
<mjrosenb> namely, it seems to insert snippets of thumb2 code
<mjrosenb> when in fact that doesn't exist
<armin76> mjrosenb: on ubuntu the default configuration options for gcc enable thumb2 code, iirc
<mjrosenb> armin76: iirc, I built with -march=armv6
<mjrosenb> I don't think I added -marm
<suihkulokki> mjrosenb: the compiler will include bits from libgcc et all, which have thumb2/armv7 cide
<suihkulokki> cide..code
<mjrosenb> suihkulokki: right, so how does building an arm compiler with crosstool-ng and not putting anything armv6 specific in it prevent this from happening?
<mjrosenb> oh, or does it default to something ancient like armv4t
#ubuntu-arm 2013-01-13
<mrspinx> Hi I am looking for the latest builds for the nexus7 I am looking at the git repository and I am thinking of installing the stock image
<jon654> does anyone know how to put Windows Ce Or UBUNTU on a Generic Android 2.2 Tablet (it doesnt have sync cable, but does have microsd, and is a tablet, not a netbook AKA Eken m009s or WM8650)?
<jon654> does anyone know how to put Windows Ce Or UBUNTU on a Generic Android 2.2 Tablet (it doesnt have sync cable, but does have microsd, and is a tablet, not a netbook AKA Eken m009s or WM8650)?
<jon654> does anyone know how to put Windows Ce Or UBUNTU on a Generic Android 2.2 Tablet (it doesnt have sync cable, but does have microsd, and is a tablet, not a netbook AKA Eken m009s or WM8650)?
<jon654> How can I install ubuntu on an android device?
<XorA> jon654: https://play.google.com/store/apps/details?id=com.zpwebsites.linuxonandroid&hl=en ??
<jon654> Yes XorA, but I want to completely take off android and put on ubuntu instead
<XorA> jon654: then you probably need to compile your own kernel and install it, then I would point it to the SD card with a Ubuntu FS on it
<jon654> please explain
<XorA> jon654: without a sync cable though installing a custom kernel could be difficult
<jon654> when i have installed android updates, it boots off the sd card, but when using and .iso extracted, it wont boot from the sd
<jon654> XorA
<XorA> jon654: I suspect this task is beyong a beginner, and each device is different so I couldnt give you a guide!
<jon654> i just bought the cheapest chinese tablet with two names, EKEN M009s and MID WM8640
<jon654> it had 256MB Ram, 4GB Disk Space, Android 2.2, webcam
<jon654> and it is called generic
<XorA> jon654: do you have a local LUG?
<jon654> what is LUG
<XorA> Linux Users Group
<jon654> Whats that?
<XorA> bunch of geeks get together drink beers and solve issues like this
<jon654> no
<jon654> I have had ubuntu in the past, but now i want it on my tablet
<XorA> https://en.wikipedia.org/wiki/Linux_user_group
<lilstevie> 256MB ram will not be a nice experience though
<XorA> trouble is here there is very little likely hood of finding someone with same tablet
<jon654> oh ok
<XorA> lilstevie: is the man if you buy a Transformer :-D
<jon654> I have had 1GB ram and it was super fast
<jon654> so 256Ram for a tablet should be fast for ubuntu
<jon654> just slow for android
<lilstevie> hehe
<lilstevie> jon654: not really
<lilstevie> I have ported ubuntu to 3 tablets now
<lilstevie> 1 with 512MB ram and 2 with 1GB
<jon654> could you help me port it onto mine?
<lilstevie> and 512 is painful
<XorA> 256 is like 1999 memory levels :-D
<jon654> i really don't care about speed for what I'm using it for
<jon654> :)
<lilstevie> it isn't speed
<XorA> just loading firefox takes 100+M
<lilstevie> I call the device with 512MB RAM Crashy McCrashCrash
<jon654> Ok, but it's good enough for me
<lilstevie> cause LowMem killer
<jon654> hahaha!
<jon654> :)
<jon654> can you tell me how to port it to my droid tab?
<lilstevie> open more than 3 or 4 tabs in Chromium of Firefox and say goodbye to Chromium or Firefox
<lilstevie> with great difficulty if you have no idea what you are doing
<lilstevie> you need to be able to compile a kernel
<jon654> how can i do that?
<jon654> I have the iso ready
<lilstevie> and be comfortable with flashing it/configuring it
<lilstevie> and no iso is going to help
<jon654> i have the Ubuntu12.10.iso
<jon654> but what should i do to port it over to the tablet?
 * lilstevie walks away
<jon654> lilstevie?
<jon654> hello?
<jon654> Has anyone else ever ported Ubuntu onto an android tablet? by taking off android and putting on ubuntu?
<lilstevie> jon654: ubuntu will not run on your tablet
<lilstevie> the tablet runs an ARM9 (ARMv5) SoC, ubuntu only supports SoCs that are ARMv7
<jon655> hello?
<jon655> lilstevie, what about Ubuntu 8?
<lilstevie> jon655: past EOL
<jon655> 8.04, im downloading it from Ubuntus site right now
<jon655> lilstevie
<lilstevie> let me guess you downloaded an iso
<jon655> maybe....
<jon655> yes i did
<jon655> lilstevie
<lilstevie> arm versions of ubuntu do not ship in ISOs
<lilstevie> you are just randomly downloading isos thinking it will work, yet you haven't even investigated compiling a kernel
<sim590> Hey! Anyone's got an idea for helping me about the post I've just made on: http://forum.xda-developers.com/showthread.php?t=1683145&page=57 (Jhinta kernel for lilstevie ubuntu)
<lilstevie> sim590: a few things
<sim590> yes yes, I'm quiet and listening
<lilstevie> apply_binaries does not register the binaries correctly as far as ubuntu expects (with update-alternatives), jhintas kernel doesn't support the latest release of tegra drivers this is why the package didn't seem to work
<lilstevie> unity does not work at this time with tegra drivers
<sim590> ok, so I'm better with lxde I guess
<lilstevie> also I would advise caution when using jhintas kernel, it is a fluke that it even works
<sim590> I posted the link to the kernel I use. I don't know if it's jintha's kernel really..
<jon655> lilstevie
<jon655> i am using this kernel now
<jon655> http://www.youtube.com/watch?feature=player_embedded&v=FfbnpfMGTAU
<jon655> the one he listed
<jon655> i'll see if it works
<jon655> 14 minutes left to extract
<lilstevie> jon655: <lilstevie> arm versions of ubuntu do not ship in ISOs
<jon655> i know
<jon655> it wasnt an iso
<lilstevie> then why did you say yes when I asked you if you downloaded an iso
<jon655> that was before this one
<lilstevie> and more importantly what did you download
<jon655> It's Arch Linux for ARM
<lilstevie> and that kernel is for your device yes? cause in that video isn't it a different device
<jon655> i believe so
<jon655> It is the netbook version of my tablet
<lilstevie> then that is not the same thing
<jon655> With the same WM8650
<jon655> It contains the same processor as my tablet
<lilstevie> that means nothing
<jon655> Its the same android just with a touch screen and with a keyboard attached
<lilstevie> Sasmsung Galaxy Tab 10.1, Asus Transformer TF101, Motorola Xoom, Toshiba Thrive, Acer A500 all use the same Tegra2 cpu yet each has a different kernel, why? cause they are not the same device
<jon655> They are both Wonder Media Tablets! Mine has two names, EKEN M009s, and Wonder Media WM8650... This is by the same people!
<jon655> with just 2 differences
<lilstevie> ok,
<jon655> in the description he writes tablets for the download, not netbook
<lilstevie> Asus Transformer prime and Asus Nexus 7 are by the same people yet run different kernels
<jon655> in the description he writes tablets for the download, not netbook
<lilstevie> point is be prepared that the kernel may not work
<lilstevie> cause arm kernels tend to be horribly device specific
<jon655> k
<jon655> Noskcaj
 * jon655 wow
<jon655> lilstevie you still here?
<sim590> aasodk
<sim590> oops (cat)
<sim590> anyone uses links2 as web browser?
<teiler> pandaboard: how do I restore my previous kernel if the new one doesn't boot?
<infinity> teiler: The previous one should be on the SD card's first parition backed up as uImage.bak and uInitrd.bak
<infinity> teiler: You can swap them back and it should boot fine (assuming this was done by flash-kernel)
<teiler> ok, but how?
<infinity> Well, either on another machine with an SD reader, or interrupt the uBoot process and do it by hand.
<infinity> Running something like: http://paste.ubuntu.com/1527006/
<infinity> (This is what boot.scr on the SD card runs in uBoot automatically, but with .bak added to the two image files)
<lilstevie> I hope building for ubuntu phone isn't as head-deskish as building desktop applications for windows rt is
<infinity> lilstevie: Well, it's just Ubuntu on the underside.
<lilstevie> infinity: and windows rt is windows on the underside
<lilstevie> :p
<infinity> lilstevie: Now, I'm still not sure where things will go as far as "app frameworks" and "official APIs", but for people doing native work, it's just Ubuntu.
<infinity> lilstevie: Well, I a bit more "just Ubuntu" than RT is "just Windows".  As in, it's the same archive repository, the same binaries.  Self-hosting, you can build natively, no need for cross sandboxes and voodoo.
<teiler> infinity: thanks. I was looking for a command reference for this shell. Is it uboot?
<infinity> s/I a/it's a/
<infinity> teiler: It's uBoot, yes.
<lilstevie> infinity: windows rt doesn't require too much voodoo, they just haven't offered the framework libraries in the sdk
<infinity> teiler: It does have a help command though I suppose the help is a bit arcane.
<lilstevie> that is pretty simple
<infinity> lilstevie: Ahh, yeah, I haven't looked at RT, due to a lack of carefactor.
<infinity> lilstevie: But in our case, it's all there.  Or, will be once the UI stuff lands in the archive.
<lilstevie> infinity: sadly native compilation on ubuntu phone will solve 99.9% of the issues Visual Studio presents
<teiler> well, what puzzled me was the device taxanomy
<infinity> (And, of course, we're working hard on making or cross-building story less crap too, if you've noticed but, still, the joy of a self-hosting platform and ARM devices being pretty speedy these days is that you can just go native and it works)
<lilstevie> infinity: with SoCs like S4 and beyond (aarch64, big.LITTLE, etc) building on device isn't scary anymore
<infinity> lilstevie: I've been saying that since the Cortex-A8.
<infinity> lilstevie: But yes, the situation just keeps improving.  A15s are really impressing me a lot more than I thought they would when I first saw them on paper.
<lilstevie> infinity: My dual-core S4 does not perform much worse than my quad-core A9
<lilstevie> which is a damn good sign
<infinity> And someone announced an 8-core big.LITTLE at CES.  Forgot who already.
<RaYmAn> Samsung
<RaYmAn> Exynos 5 'octo'
<infinity> 4xA7, 4xA15.  Curious to see how it'll work in practice, rather than theory.
<infinity> RaYmAn: Right, thanks.
<infinity> Getting old, trivia just slips in one ear and out the other these days.
<lilstevie> that will be interesting
<lilstevie> I didn't really pay much attention to CES
<lilstevie> most of it was pretty boring crap
<infinity> Then again, even if we're all still scrambling to make big.LITTLE scheduling as awesome as possible, just firing it up with the 4xA15s and ignoring the A7s will be fine for my use cases. :P
<lilstevie> heh
<lilstevie> what would really make my day is being able to turn on both CPU Complexes at once
<infinity> Most of the big.LITTLE people I've talked to have mentioned that as a nice-to-have goal.
<infinity> For people like me who don't give a shit about power and just want as much juice as possible.
<infinity> But, it makes SMP scheduling a bit of a nightmare to have mismatched CPUs.
<infinity> Cause timeslices are no longer equal units.
<infinity> And, to be fair, the A7 is intentionally so much slower than the A15 that you might not really care about the modest performance boost anyway.
<infinity> Especially after you factor in the complexity overhead, plus the development time that went into the shiny. :P
<lilstevie> Given that they should be living on 2 different buses (with one central) that you may be able to async between the complexes while maintaining SMP in each complex
<infinity> I do kinda wonder why they didn't just go with big.BIGGER as the model.
<lilstevie> that would be cool
<lilstevie> but probably power profile
<infinity> (As in, a bunch of identical cores, but recommend that you turn all but one off and frequency scale that one into the ground)
<sim590> anyone got an idea why linux would put a filesystem in readonly? I got a guess: dpkg tried to access to some corrupted file. Seeing it was corrupted, linux put the FS in read-only FS. Does this make sense?
<infinity> But I get the impression the A7 part itself is just plain designed to be far more efficient than the A15.
<lilstevie> trying to make little as power efficient as possible
<infinity> sim590: dmesg may give some clues.
<lilstevie> sim590: RO is considered safe but yeah check dmesg
<infinity> sim590: But as a general rule, if your filesystem throws errors, your kernel will remount it RO to prevent you from damaging it further until you can sort it out.
<infinity> lilstevie: I do look forward to big.LITTLE in practice on smart phones, though.  I dream of a day when my smart phone can go two days without charging. :P
<infinity> (Who else misses all the old Nokia feature phones that went a week?  Seems like forever ago now)
<lilstevie> infinity: agreed
<lilstevie> I miss feature phones for that reason
<sim590> thanks guys. I'll try to trigger the error again and look dmegs
<lilstevie> I miss the good old days of "oh, my phone is bleeping at me, what do you know it has been like 8 days since I charged it"
<lilstevie> then as phones got more advanced and their battery lives started dropping I thought, ok fair enough, give it time for the battery tech to catch up. Now here we are years later and stuck at 1, maybe 2 days if you are lucky
<infinity> Maybe I should throw my SIM in my old Sony W700 and see how long I can survive without a web browser and apps.
<infinity> At least it was a good music player.
<infinity> And it probably wouldn't take long to relearn T9.
<sim590> infinity,lilstevie: Thanks for your advice guys
<infinity> Oh, except I'm on a cheap carrier than doesn't actually offer GSM service, so I'd be perpetually roaming.  That would be problematic. :P
<lilstevie> heh sometimes I consider trying to find a nokia 1100 again, I used to consistently get 8-10 days from that thing
<infinity> I probably still have my 8860 in a box somewhere.
<lilstevie> heh
<infinity> Oh, wait, no, it was an 8850.
<infinity> The 8860 was the silly North American TDMA model, and I had that phone in Australia.
<lilstevie> ah
<lilstevie> as long as it is not TDMA it will probably still work here
<infinity> The 8850 is GSM 900/1800
<infinity> Should work on a fair few carriers still.
<lilstevie> yeah that would work just fine here
<lilstevie> on my carrier
<infinity> It was pretty, too.  I've mostly forgotten how much design went into these things.
<infinity> Before we all started carrying black rectangles.
<lilstevie> yeah
<infinity> "The phone's memory can store up to 250 names and 50 calendar notes. SMS messages can only be stored on the SIM card."
<infinity> ^-- How did that not drive me insane?
<lilstevie> oh...my...god that just reminded me
<infinity> I have tens of thousands of text messages on my current phone, that wouldn't fit on a SIM. :P
<lilstevie> of the hell
<lilstevie> "Your phones simcard is full please delete some text messages"
<infinity> *grin*
<infinity> The good old days.
<lilstevie> yep
<lilstevie> back in the day when having 30 text messages was it
<infinity> I suspect I spent more time talking to people in person back then.
<infinity> Yay, progress.
<lilstevie> yeah
<lilstevie> or talking on the phone
<lilstevie> now days it is all text
<lilstevie> I know my old phones spent a lot more time against my ear than new ones
<lilstevie> the new ones*
<teiler> infinity: http://paste.ubuntu.com/1527006/ root=UUID=c8fabf2c-f023-41d8-83bd-98dcde49d64f won't work â¦
<infinity> teiler: Erm, yeah, that's my root device, not yours. :P
<infinity> teiler: Is your root on the SD card or an external USB drive?
<teiler> SD card
<infinity> teiler: You'll want something like "root=/dev/mmcblk0p2" probably.
<lilstevie> hah
<lilstevie> you can probably also get your uuid from the boot.scr/boot.cmd on your u-boot partition
<infinity> lilstevie: Yeah, but if he could get at his SD card, he could also just swap uImage and uImage.bak.  I get the impression he's not flush with non-Panda SD readers.
<lilstevie> ah
<lilstevie> I thought u-boot had a cat like command though
<infinity> Plus, mmcblk0p2 is a hell of a lot easier to type than a UUID. ;)
<lilstevie> true
<lilstevie> also that said, I do only have 1 device with u-boot and I don't tend to poke around its console very often
<infinity> Yeah, I can't find a catish thing in the first reference sheet I googled.
<infinity> You can fatls directories, but no fatcat or similar.
<infinity> Shame, cause fatcat would be an awesome command name.
<infinity> I'm being stared at by a fat cat right now, actually.
<infinity> I think he thinks it's breakfast time cause I'm awake. :/
<lilstevie> lol
<lilstevie> ffs why do people think it is a good idea to hardcode something like /MACHINE:X86 even though there is the same option elsewhere which is controlled by the target platform
<infinity> This is why I love free software, at least.
<infinity> Can you imagine the pain of the poor porters who had to sift through the Windows codebase after more than a decade of no one caring about it being portable?
<lilstevie> haha
<lilstevie> yeah
<lilstevie> it is painful enough that some of this stuff depends on cpucontext
<lilstevie> which doesn't quite line up
<lilstevie> (direct register access)
<infinity> Though, they could surprise me.  Maybe they maintained internal port builds all along to prevent just that sort of oops.
<lilstevie> from what it sounds like it is a cleanroom port
<infinity> Yeah.  Sounds more likely.
<lilstevie> a lot of the outdated crap is gone
<infinity> I somehow doubt the portability of NT4 survived 15 years.
<lilstevie> or so I hear
<teiler> infinity: it worked, thanks.
<lilstevie> there should be at least a little portability in the original code
<infinity> Well, as much as any generic C and C++ is portable, obviously.
<infinity> But I'm sure there are x86isms all over the effin' place too.
<lilstevie> given that NT4 ran on mips and alpha
<infinity> At least they don't have to care about endianisms this time around.
<lilstevie> and there has been Itanium for a lot too
<infinity> Yeah, MIPS, Alpha, and PPC.
<infinity> I don't know that I ever actually saw an NT ia64 port in the wild.
<infinity> Though I'm sure it must have existed.
<infinity> All the ia64 kit I met ran HP/UX (or Debian).
<lilstevie> hm
<lilstevie> I am not sure, doesn't appear to be an IA64 version that I can find
<teiler> inifinity: I made a dist-upgrade frrom 12.04 to 12.10, but it seems there is no omap4 linux packet any more?
<infinity> teiler: linux-omap4
<infinity> teiler: Definitely exists.
<infinity> If you've done something strange to remove it, just "apt-get install linux-omap4"
<infinity> Oh, unless you're running armel...
<lilstevie> that would probably not go down well
<lilstevie> :p
<infinity> We didn't officially support armel for 12.04 for a reason. :P
<infinity> And dropped the kernels from armel in 12.10.
<infinity> (And dropped the userspace in 13.04)
<infinity> So, in conclusion, use armhf. :P
<infinity> And I should get some sleep.  It's 6am.
<lilstevie> infinity: lol wow yeah get some sleep, 23:51 here
<lilstevie> :p
<teiler> infinity: 'No candidate version found for linux-omap4'
<lilstevie> yeah probably cause of armel
<infinity> teiler: Yeah, like I said...
<infinity> teiler: If you installed precise/armel, you were installing a dead-end and unsupported platform.  We tried to make that clear.  Maybe not clear enough.
<infinity> teiler: You want armhf.  It's the way and the light.
<lilstevie> I wonder when canonical is going to say screw armv7 and move to armv8
<lilstevie> :p
<infinity> Well, we're doing aardvarch64 stuff pretty heavily right now.  But I doubt we'll drop armhf any time soon.
<lilstevie> yeah
<infinity> Plus, there may always be a neat use-case for armhf/arm64 multiarch for 32-bit goodness on your 64-bit kernel.
<lilstevie> one big stopper on dropping armhf is no aarch64 stuff available :p
<lilstevie> and I suppose aarch64 has the ability to multiarch a bit better
<lilstevie> like x86/x86_64
<teiler> infinity: so how do I switch? Can I dist-upgrade?
<infinity> teiler: No.  You're pretty much stuck reinstalling.
<lilstevie> teiler: the best way is to download a new image
<lilstevie> dist-upgrade will leave you in a horridly broken state
<infinity> teiler: Cross-grading arches is a stretch goal for multiarch, but it doesn't really work without a lot of manual fiddling right now.
<infinity> And isn't worth the effort of trying.
<Tassadar> hmm, nexus 7 has "serial debug shell" thing, where you can just "screen /dev/ttyACM0 115200" into the shell via usb
<Tassadar> is that just kernel thing or must be something in userspace running?
<kulve> Tassadar: you need to have login running in user space on correct port. It's ttyGS0 on nexus side
<Tassadar> ah, that's what getty is for
<Tassadar> now to figure out where should it be started in archlinux
<itu>   hi
 * itu would like to get some linux on his Jay-tech 9903H mini-netbook
<Tassadar> ha, there it works now, thanks
<Rjs> hmm, that reminds me: is there support in the ubuntu nexus7 kernel for the USB ethernet gadget device? on my openmoko gta02, I'm used to ssh'ing in via the USB connection (it's more versatile than just a serial port, for file transfers etc.), and I'd like to get the same on nexus7...
<kulve> Rjs: at least it's possible to recompile kernel so that it's supported (usb0). I'm not sure if that's on by default with ubuntu's config
<kulve> g_multi supports both the getty and the usb0 at the same time
<Rjs> kulve: ok, g_multi sounds very good :) (just found drivers/usb/gadget/Kconfig in the kernel source) thanks! I'll try that when I compile my own kernel
<Rjs> hmm, there's also USB_CDC_COMPOSITE which seems to have only serial + ethernet, while USB_G_MULTI also has mass storage (and is marked EXPERIMENTAL), maybe composite is better for me
<kulve> if you run into compilation problems with fsl lock something functions related to those, just comment them out..
<Rjs> ok, I'll keep that in mind (not trying it right now, maybe later today or tomorrow)
<Rjs> it's not on in ubuntu's default kernel: only CONFIG_USB_SERIAL=y in /proc/config.gz, the other CONFIG_USB_G_* are unset (i.e., not even compiled as modules)
<marvin24> how to solve "Cannot build any of the architectures requested: armel armhf" ?
 * marvin24 hopes this is the right channel
<jj234> is there any reason why my install of the omap4 preinstalled image wouldn't set $HOME for root?
<jon654> Hello, I'm trying to install ubuntu on a tablet, Does anyone know how to boot android device from the sd card slot
<jon654> How could i root it, it's a chinese generic Tab.
<kulve> all devices are different, no generic rule
<jon654> It;s known as Eken M009s/MID v7/WM8650
<jon654> Hello, I'm trying to install ubuntu on a tablet, Does anyone know how to boot android device from the sd card slot. How could i root it, it's a chinese generic Tab. It;s known as Eken M009s/MID v7/WM8650
<stgraber> jon654: You've been told that already yesterday and things didn't change overnight, Ubuntu won't work on this tablet as it's an ARMv5 and we only support ARMv7
<jon654> Not even an older version stgraber?
<stgraber> the last time Ubuntu was fully built for ARMv5 armel, was around jaunty/karmic IIRC, neither of those are still around today
<stgraber> and as other people told you, even if you get a userspace that works for your tablet, you'll still need to build a kernel for it yourself as that specific ARM platform has never been supported by Ubuntu or Linaro
<Sammy> Hey Guys!
<Dj_Sammy> Someone there ?
<k1l> 147 users
<Dj_Sammy> Can someone please reply?
<k1l> !ask | Dj_Sammy
<ubot2`> Dj_Sammy: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<Dj_Sammy> OKay... Im sorry for that :S
<Tassadar> I like that bot Oo
<komradefox> i used a usb keyboard on ubuntu on my nexus7, but when i reboot without the keyboard plugged in, i can't get a virtual one to sign in
<Dj_Sammy> I want install Ubuntu on my Nexus7 16 G w/o Cellular. First: I must unlock the Kernel... But do i need an installed UBUNTU System on my PC? ?
<Tassadar> komradefox: one of the icons in upper right corner should turn it on
<komradefox> Tassadar: ah yes, thank you
<komradefox> does the software update work on the n7?
<komradefox> oh hmm i guess not, i get an error
<komradefox> failed to fetch, sum mismatch,
<Dj_Sammy> Tassadar?
<Tassadar> You don't, but it is much easier
<Tassadar> just download the live cd and boot from it, that should be enough (I am not "from ubuntu")
<Dj_Sammy> ive got some old pc's, ill think that will work too
<Tassadar> komradefox: it should
<Tassadar> apt-get update && apt-get (dist-)upgrade works for me
<komradefox> huh, i followed a guide to clear my apt. http://ubuntuforums.org/showpost.php?p=11951697&postcount=2
<komradefox> and that fixed it
<komradefox> something must have gotten corrupted was all
<simon> Anyone got this error with Lilstevie ubuntu (updated to 12.04, k2.6.36.4) when from a certain point after installing it.. It only reboots in readonly FS?
<sim590> no matter if I run e2fsck.. it still does this
<sim590> nvm.. It seems like fsck doesn't fix it really.. but e2fsck fixes it. For now it seems to work. You guys can light down Gondor's alarm firelights!
<jj234> my u-boot command line contains "splash," is there any reason why I wouldn't still get a splash screen?
<jj234> i have plymouth installed
<sim590> well, it just randomly went back to read-only file system..
<Tassadar> sim590: try to run dmesg, maybe there is more info in there
<sim590> Yeah.. I've just done that and it says: [sda] Device not ready, [sda] Result: hostbyte=0x00 drivebyte=0x08,[sda] Sense key : 0x2 [current] ........... I/O error, dev sda, sector 6578354, lost page write due to I/O error on sda1
<Tassadar> it's usb flash drive?
<sim590> I'm using the SD card on the keyboard of the TF101
<sim590> it's my rootfs
<Tassadar> it is quiet possible that it the sdcard is corrupted
<sim590> maybe I should use micro sd card
<Tassadar> *quite
<sim590> Or may be it sometimes has some bad contact with between the tablet and the keyboard
<sim590> therefore, the journal is messed up
<Tassadar> you could try to connect it to computer or something
<sim590> I/O error wouldn't indicate that there's a connectivity problem?
<Tassadar> well, it can as well might be that the sdcard is bad
<Tassadar> I know that USB drives do that
<sim590> my sd card is new
<sim590> I've just bought it
<Tassadar> then it is probably just bad contact, as you say
<sim590> that's unfortunate.. I've bought that for nothing and costed 40$..
<sim590> 32Go.. it's going to cost double the price for micro SD
<Tassadar> I dunno how is sdcard connector mad in TF101, but can't you just, I don't know, put a piece of paper or something on top of the card so that the contact is correct?
<Tassadar> *made
<sim590> may be the problem is from the connection between the tablet adn the keyboard
<sim590> you know where the table fixes itself. It's a little bit mobile there
<sim590> it moves a little bit
<sim590> may be the bad contact is there.
<Tassadar> I'd really just try to stick that sd-card to computer and try if it is not bad
<Tassadar> or try to use some other sdcard with the tablet
<sim590> The sd card is ok. I use it with my pc and it always mounts
<Tassadar> well, mount is one thing, have you tried to actually transfer some data to it?
<sim590> the image i put on it took 2hours to dd
<sim590> and everything was fine
<sim590> it corrupts itself only when I put it in TF101
<Tassadar> btw, how big was the image you dd-ed to it?
<sim590> About 30Go
<Tassadar> oh, okay, 2 hours seemed a little too much to me, but if the image is that big, then it's okay
<Tassadar> well, I don't have anything else to tell, just try to make sure that the contacts are correct, but I guess you can figure that out)
<sim590> I could resize it to less than this in order to take less time, but if I want to take advantage of the whole space on the partition, I have to resize it afterwards on the TF101
<sim590> Thank you for your assistance, it's good to see we can get some echo
<sim590> I just blow air in the slot. I hope it helps ^^
#ubuntu-arm 2014-01-06
<janimo> infinity, congrats on being elected to the TB
<ogra_> ++
<coreyfro> Hey all.  I am interested in learning how to prepare packeges for a PPA for ARMHF, but in my research, I have seen that launch pad only builds x86 and AMD64 binaries (https://help.launchpad.net/Packaging/PPA)  Is there documentation for people who wish to build binaries for ARM systems?  I mean, literally, it doesn't even make sense to have x86 and AMD64 versions of my packages, but I NEEED to have armhf versions.
<infinity> coreyfro: https://answers.launchpad.net/launchpad/+addquestion
<infinity> coreyfro: Specify which PPA you want armhf enabled on and why, and someone will get to it.
#ubuntu-arm 2014-01-08
<sgo11> hi, I haven't installed ubuntu arm yet. I would like to know what packages and which versions are supported by current ubuntu arm release. can anyone tell me where I can check? what is the repo url? thanks.
<ogra_> the same packages that are on x86
<ogra_> the archive is at ports.ubuntu.com
<sgo11> ogra_, thanks. the latest arm release is 12.04. when you say the same packages to x86, do you mean the same packages(version) as 12.04 x86? or latest 13.10 x86? thanks.
<ogra_> the latest arm release is 13.10
<ogra_> arm is built in parallel since 9.04, since then you have the identical package versions to x86
<sgo11> ogra_, thanks. I come from https://wiki.ubuntu.com/ARM. it shows 12.04 release. what is the official site for ubuntu arm? where to get 13.10? thanks a lot.
<ogra_> oh, dont trust the wiki ... it is always outdated :)
<sgo11> ogra_, thanks. but where to get the latest arm release? thanks.
<ogra_> there is no official site specific for arm anymore ... it is just another architecture
<sgo11> ogra_, ok. so how can I install 13.10 to my board? can you show me some guideline/tutorial? thanks.
<ogra_> which board is that ?
<sgo11> ogra_, cubieboard (cubieboard3 also named cubietruck)
<ogra_> installation images are very device specific since kernels and bootloaders vary massively on arm ... there are only images for a few devices/boards
<ogra_> ah, well, there is definitely no official cubieboard image, so google is your friend ... i'm sure there are some third party howtos to get ubuntu running on that device though
<sgo11> ogra_, yeah. I am a newbie to arm. I am very confused on how to install them.
<sgo11> ogra_, the official cubieboard team release ubuntu 12.04. I just want to get latest packages. maybe I should think switching to archlinux-arm even if I never use archlinux before. but archlinux-arm provides official release to cubieboard.
<sgo11> installation to arm world becomes very different. installation in archlinux becomes much easier than ubuntu.
<ogra_> just use theirt image then, you can always just upgrade to 13.10
<ogra_> huh ?
<ogra_> i highly doubt that
<ogra_> if there is an existing ubuntu image, just install it ... most likely you just need to dump the image onto an sd card and are good to go
<ogra_> arch means you will have to know how to build your own stuff from scratch etc ... it will definitely be a lot harder than using a binary distro like ubuntu debian or fedora
<sgo11> ogra_, archlinux-arm provides a specific image to my cubieboard. that's why I thought that might be easier. haven't tried it yet. I can use "sudo apt-get dist-upgrade" in ubuntu arm to upgrade to 13.10? thanks.
<ogra_> unless you are already good at linux in general and in arch specifically
<ogra_> sgo11, http://cubieboard.org/download/
<ogra_> just grab the lubuntu image from there and be happy
<ogra_> (first hit on google btw)
<sgo11> ogra_, sorry about my bad memory. that is 12.10 instead of 12.04. but the team does not provide 13.10. how to uprgrade to 13.10 once I have 12.10? thanks.
<ogra_> sudo update-manager-core
<ogra_> that will upgrade you to the next ubuntu version
<sgo11> ogra_, cool. I will do that and stick with ubuntu. thanks a lot for your help.
<ogra_> err, sorry
<ogra_> update-manager-core is the package
<ogra_> it is sudo do-release-upgrade
<sgo11> ogra_, no problem. what is the command? if you can tell me, it will save my time to google. :) thanks.
<ogra_> sudo do-release-upgrade
<sgo11> ogra_, oh. it's always that command. never really use it in x86 world. I always did fresh install in x86. but arm is different. thanks a lot.
<ogra_> arm is the same :)
<ogra_> the only things that usually differ on arm are the bootloader and kernel which are board specific
<sgo11> ogra_, that's very cool. thank you very much! ^_^
<sgo11> ogra_, since you are here, may I ask another question related to kernel rebuilding? can I use the same new way (https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel) to compile the kernel in arm? "fakeroot debian/rules binary-headers binary-generic" thanks.
<ogra_> only if your kernel source has a package dir (which it is unlikely to have)
<ogra_> the guys in #ubuntu-kernel might be able to give you more hints, but generally if you have a non official board you just build the kernel without packaging and maintain it separately
<sgo11> ogra_, i have a driver which requires rebuild the kernel to work. that's why I asked this question in advance.
<ogra_> well, best to ask in a cubieboard forum tzhen
<sgo11> ogra_, sure. I will do that. thank you very much. ^_^
#ubuntu-arm 2014-01-09
<twb> lilstevie: hey, I'm finally losing patience with my TF101 -- got any recommendations for good netbooks (or tablets w/docks) to run Ubuntu/Debian on?
<lilstevie> twb, at present? nope
<lilstevie> maybe an arm chromebook if you are still into arm
<twb> I'm actually a bit sick of arm's wackiness.
<twb> But most of all I want a real SSD
<twb> But the 10" x86 netbooks are all pretty sucky for battery life, so I figured I'd at least ask what was around in the ARM space
<wookey> what's the recommended way to install ubuntu remotely on a machine (using a custom kernel)?
<wookey> just debootstrap onto the rootfs then stick the kernel and modules in place and re-run initramfs bits?
<wookey> (the machine is already booted so I can run debootstrap on it, with the root-to-be mounted)
<rbasak> wookey: I basically do that, but without an initramfs.
<wookey> isn;t killing the initramfs tricky with plymouth etc?
<rbasak> In my case I had a separate issue with plymouth so had to disable it anyway
<rbasak> The only issue I had with turning off plymouth was that lightdm didn't start, since it was waiting on plymouth-done or something. Apart from that disabling plymouth didn't cause any issues for me. But this was a while ago.
<rbasak> But since I had to disable plymouth anyway, I don't know if it would have caused issues.
<ogra_> rbasak, until you have your first fsck errors :)
<ogra_> it works fine without plymouth until mountall wants to talk to the user in any way ... then it breaks badly
<digitlman> can anybody tell me where I can find the latest BCM40181 drivers?
<ogra_> at broadcom perhaps
<ogra_> (how is that related to ubuntu)
<digitlman> not that I can find....
<digitlman> it is called casting a wide net
<Tassadar> ogra_: somebody here was asking for some kind of mirrors for system-image.ubuntu.com (it was slow for him) the other day, is that planned? Now it is just one http server server for everyone (or is it?), whereas normal desktop ubuntu images are hosted on several mirrors, torrents and they support zsync.
<ogra_> currently it is only one server
<ogra_> stgraber might know if there are any mirror plans
<ogra_> (i assume once we actually have a million devices out there we seriously want mirrors :) )
<ogra_> (currently the user base is rather in the 4-5 digit area i guess though)
 * Tassadar realizes he selected the wrong channel
<ogra_> :)
<ogra_> well, still kind of related
<Tassadar> the current update system doesn't seem to be prepared for that at all, although I suppose it can be done on server level(?)
#ubuntu-arm 2014-01-11
<sgo11> hi, there is no "ubuntu-restricted-extras" in the repo. how to install it? thanks.
<sgo11> hi, how to install flash player to chromium ?
<infinity> sgo11: On ARM?
<infinity> sgo11: You can't.  There's no Flash binary for ARM Linux.
<infinity> (Complain to Adobe, not us)
<sgo11> infinity, got it. thanks.
<sgo11> I thought I can use arm board to replace my laptop. but too many problems. i kinda give up this idea.
<sgo11> hi, where can I find a list of all mirrors for http://ports.ubuntu.com/ubuntu-ports ? thanks a lot.
<lilstevie> sgo11, I don't believe ports is mirrored much, if at all
<sgo11> lilstevie, ok. thanks.
<infinity> lilstevie: It has one mirror (us.ports).
<infinity> lilstevie: And all the country codes are set up (but either point to uk or us for now) to allow for future expansion.
<infinity> sgo11_away: ^
<lilstevie> infinity, so as I said, not much, and practically not at all :p
<sgo11> infinity, thanks a lot.
<sgo11> hi, how to setup default input method to ibus in lxde? I tried gnome-language-selector, but it fails to start. it reports "Could not get owner of name 'org.freedesktop.Accounts': no such name" error. thanks.
#ubuntu-arm 2014-01-12
<sgo12> I am using lxde. Battery Monitor in lxpanel is not correct. it always shows 0% charged. how can I set it correctly? thanks.
<sgo12> I just install acpid. but the Battery Monitor still shows 0%
<sgo11> hi, I can check battery capacity from the file "/sys/class/power_supply/battery/capacity", but in lxde, lxpanel's "Battery Monitor" can not detect those correct value. how to fix this? thanks a lot.
#ubuntu-arm 2015-01-07
<nagerst> is it possible to use the libflasplayer.so from flashfox in ubuntu as a browserplugin?
#ubuntu-arm 2016-01-15
<binaryplease> Im looking for Odroid-XU4 ubuntu server images, official website has desktop only. Are there any or shall I just remove all desktop packages from the desktop version?
<k1l> see http://odroid.in/ubuntu_14.04lts/
#ubuntu-arm 2018-01-10
<promach_> As in https://paste.ubuntu.com/26357027/ , I could not boot up my Ubuntu for Zedboard after an interrupted major upgrade. What should I do ?
<promach_> For https://paste.ubuntu.com/26358306/ , what does "mmc0: Card stuck in programming state! mmcblk0 mmc_blk_err_check" mean ?
<promach_> what do you guys think about https://paste.ubuntu.com/26360019/ ?
