[00:00] [ 35.623962] musb_hdrc musb_hdrc: musb_init_controller failed with status -19 [00:00] [ 35.643035] last sysfs file: /sys/devices/platform/gpio-keys/input/input0/event0/uevent [00:00] er, missed this in the middle: [00:00] [ 35.639160] Internal error: : 1028 [#1] [00:01] DanaG, give this one a try, it's my current work in progress.. http://rcn-ee.homeip.net:81/dl/testing/lucid/linux-image-2.6.33-500-omap_2.6.33-500.3_armel.deb [00:03] I'm going to be leaving soon, but I'll give it a try later. [00:04] Is it possible that the u-boot usbtty is interfering? [00:04] ...even though I'm not using it. [00:04] no problem, i'll be working on a couple things, so just watch the bzr repo i use... i don't know if that's ready for the c4 board yet... [00:05] nah it shoudn't... [00:19] hello [00:20] howdy doody [00:20] What can i put on my Asus A636 [00:20] ? [00:20] Hi rcn-ee [00:21] it looks like it's xcale... [00:22] pxa270, i think that's armv4, which would mean, angstrom or debian... [00:23] great [00:23] Some ubuntu? [00:24] A few years ago i wanted to put some linux on it, but it didn't support gps an wifi ad that sucks [00:24] ubuntu's lowest minimum requirement was armv5, but that was 9.04... (9.10 requires armv6 and 10.04 is armv7) [00:24] if you can find a kernel, ubuntu squeeze should run great on it... === jussi01 is now known as Guest4656 === nslu2-log_ is now known as nslu2-log === ApOgEE__ is now known as ApOgEE [05:00] Cannot access MTD device /dev/mtd2: No such file or directory [05:01] rcn-ee: that's on the test kernel you linked. [05:17] All /dev/mtd* are missing. === Guest4656 is now known as jussi01 === Laibsch1 is now known as Laibsch [08:14] For some reason I am not capable of starting qemu-system-arm with -net tap support. I followed the instructions on the RootfsFromScratch [08:38] nosse1, i'm not using any tap devices myself, but i think it helps starting the VM with sudo in that case [08:40] lool, hmm, could it be that parted dropped support for units other than megabyte ? parted -s test.img mkpart primary fat32 0 67107840B doesnt seem to work anymore and the manpage only talks about megabyte (and gives no info about how to use other units) [08:41] LANG=C parted -s test.img mkpart primary fat32 0 67108352B [08:41] Error: The location 67108352B is outside of the device /var/build/omap-image/test.img [08:41] thats definately not true if the unit would actually be bytes [08:43] (the partitioned image with MBR is 67108352 so it should leave exactly teh needed space) [08:48] ogra: Remember that the offsets are zero based [08:48] and inclusive [08:48] ogra: So if your file is 67108352 bytes, you need to write up to 67108351B [08:49] hmm [08:49] + DISK_END_B=67108352B [08:49] intresting [08:49] where does that one byte come from then [08:50] (i'm using the dove script and try to modify it for omap atm) [08:50] oh [08:51] the script devides by 512 ... i'm using mkdosfs -C which uses a blocksize of 1024 [08:51] bah, doesnt pay off to be lazy :/ [08:51] * ogra uses dd instead of leaving image creation to mkdosfs [08:54] ogra: Using sudo with qemu worked. Thanks. [08:56] ogra: However when i start the vmlinuz the kernel log sais "eth: Ethernet addr: xx:xx" and then "eth0: No PHY found" [08:57] I have "-net nic,macaddr=xxx -net tap" as options to qemu [08:59] sorry, but i have not used tun/tap stuff since several years ... [09:00] (no idea who added it to the wiki or if it works at all) [09:01] Well the linux inside qemu assigns macaddr according to my settings, so obviously something is working [09:08] crap [09:08] so using the dove script defintely doesnt make MLO/u-boot.bin work [09:12] lool, did you change any config options in the x-loader package ? i cant make it load u-boot from SD anymore [09:22] ogra: I did not [09:24] The two things which change build flags which I changed: I reworked the -fno-stack-protector passing (but as you can see, it's in the log), I fixed passing of -Bsymbolic-functions, and I also made sure that CFLAGS were passed to HOSTCC [09:33] Is there any easy way to make qemu display more than 80x24? A kernel option similar to vga= in x86 [09:34] nosse1: Consider connecting over SSH; that will match your local terminals [09:34] ok, thanks [09:35] apt-get install openssh-server [09:35] Argh... Wrong window :D [09:37] ogra: So did you try an older binary from x-loader? [09:38] lool, no, but it seems to be related to partitioning actually [09:39] Texas Instruments X-Loader 1.4.3 (Mar 24 2010 - 21:16:42) [09:39] Reading boot sector [09:39] Error: reading boot sector [09:39] Loading u-boot.bin from nand [09:39] it works if i partition manually but not if i use the dove script [09:43] sigh [09:47] now it doesnt work with manual partitioning either :( [09:58] gah [09:58] it exclusively needs haeds and sectors [10:03] lool, do you know of any way to enforce heads and sectors with parted ? [10:03] i fear i have to resort to fdisk or sfdisk [10:04] * ogra only sees chs for unit printing in parteds manpage [10:19] ogra: I think you can use chs as an unit when creating the partitions [10:20] hmm, thats a hell lot of math [10:21] apparently MLO also doesnt work anymore if the partition is >1G [10:25] hmm, no, actually 800M [10:25] ah I know what I had forgotten yesterday [10:47] Vicious, fat16 support is broken [10:48] So only -F 32 works [10:48] and I had forgotten the bootable flag yesterday [10:52] ogra: I confirmed that x-loader and u-boot from the archive work (at least in qemu-system-arm) [10:52] lool, yeah, they do, its a partitioning issue [11:29] ogra: Hmm I wonder what the plan is for the beagleboard image? SD card? [11:30] ogra: Or NAND image? [11:30] ogra: Currently, the x-loader package is built for NAND boot [11:32] actually it seems to be turned on by default, but it attempts reading from NAND, not MMC, odd [11:32] Blank nand/onenand contents, attempting serial boot . . . [11:33] Loading u-boot.bin from nand [11:34] actually problem is: Error: reading boot sector [11:49] Hmm if I pass a NAND file to qemu, it insists from booting from it, even if empty [12:01] you guys having fun with x-loader? ;) [12:01] lool, it defaults to nand unless you push one of the keys on boot.... [12:04] rcn-ee: is there a way to change that? [12:04] rcn-ee: So I'm trying to get a SD image to work under qemu-maemo-system-arm [12:05] My SD image has MLO and u-boot.bin [12:05] but x-loader never loads u-boot [12:05] In the case where I pass -sd and -mtdblock, it doesn't even load x-loader [12:05] are you using the omap target under qemu? [12:05] Yes [12:05] well -M beagle [12:06] ARGH [12:06] -m 256 fixed it [12:06] i'm not sure if that even works... [12:06] the default memory size is just stupid [12:06] Ok, so I solved the -sd + -mtdblock issue wiht -m 256 [12:07] last i heard it working was: http://code.google.com/p/qemu-omap3/ [12:07] Now the next one is how to tell qemu to tell x-loader that I want a MMC boot, or how to configure x-loader to default to that [12:07] or how to have x-loader fallback to that [12:07] the last option is probably the best [12:07] rcn-ee: I'm using a newer branch [12:07] rcn-ee: http://maemo.gitorious.org/qemu-maemo/ [12:07] rcn-ee: I have it in ppa:lool/ports-dev [12:08] Texas Instruments X-Loader 1.4.3 (Mar 24 2010 - 21:16:42) [12:08] Reading boot sector [12:08] Error: reading boot sector [12:08] Loading u-boot.bin from nand [12:08] It doesn't try MMC [12:08] ah cool.. [12:09] Angstrom's x-loader defaults to loading it from MMC for some reason [12:09] lool, SD card [12:09] Texas Instruments X-Loader 1.4.2 (Jul 16 2009 - 01:58:04) [12:09] Reading boot sector [12:09] Loading u-boot.bin from mmc [12:09] lool, thats why i added signGP [12:10] *wow* if I pass -m to a qemu run with -sd alone, it breaks again [12:10] yeah, on real hardware you defintelly need the signGP part [12:11] lool, you need to use the MLO binary and the partitioning needs to match to make x-loader load from MMC [12:11] so -sd + -mtdblock + -m => ok, -sd + -m => breaks, -sd + -mtdblock => breaks, -sd + -mtdblock => breaks [12:11] well I've put the same twice [12:11] -sd => ok [12:12] I don't think it's a problem of signature since I can get it to work with different flags [12:12] besides, x-loader *is* loaded, just not u-boot [12:13] even weirder: -sd Angstrom image works with or without -m, only my image requires -m [12:13] Ok, I think my image breaks because it tries reading NAND and that requires -m [12:14] lool, make sure to do the partitioning of your SD image right [12:14] x-loader a) requires the boot flag to be set b) needs 255 heads and 63 sectors [12:15] without a) it will resort to the NAND x-loader (if it exists) without b) you get the bootsector issues [12:16] thats what i'm struggling with atm trying to build an image [12:18] ogra: As I said, it does get loaded [12:19] ah, i missed that in the reconnection noise [12:19] but you have the bootsector issue [12:19] My biggest problem is that our x-loader tries NAND and that either doesn't fallback or breaks qemu [12:19] that goes away for me if i use 255 heads and 63 sectors during partitioning [12:20] we don't want it to try NAND because we want to boot from MMC, even if NAND boot works [12:20] are you using MLO ? [12:20] so we need to configure our x-loader for MMC only, no NAND [12:20] ogra: Yes [12:20] we want to use NAND if u-boot cant be read from MMC [12:21] so that we have a fallback (in case there is something in NAND) [12:21] your prob is your bootsector [12:21] not our MLO [12:22] i can fully boot from MMC here with our binaries [12:22] ogra: Does it really boot from MMC? [12:22] or does it try NAND? [12:22] You don't know what's in NAND, so you can't be sure it will boot on MMC [12:22] i know whats in my NAND here [12:22] I'm fine with a x-loader which tries MMC first, but that doesn't appear to be the case of ours [12:22] ogra: You don't know what's in people's NANDs [12:23] it is for me [12:23] did you try on a real beagle or only in qemu ? [12:23] No it's QEMU alone [12:23] It might be that QEMU doesn't set the SYS flags properly [12:23] using this reciepe http://paste.ubuntu.com/397188/ with mmy SD in a real beagle gets me a full MMC boot [12:24] ogra: Are you sure it's not trying to read from NAND? [12:24] the binaires in NAND on my beagle both have a timestamp from feb 19th ... its very easy to see if it loads the MMC versions or the NAND versions here [12:24] that's the one i usually recommend, on some weird sd cards, formating as '16' vs '32' helps, but those are rare cards.. [12:25] I don't think there's any problem with my "SD card" [12:25] since it does load MLO [12:25] and it starts [12:25] lool, i'm 100% sure, yes and i have seen the "Error: reading boot sector" if the gemoetry wasnt matching [12:25] my problem is interaction between our MLO and QEMU/emulated hardware [12:25] ogra: That can be triggered by many things [12:26] well, it uses MMC if i use the above partitioning [12:26] for both, MLO and u-boot [12:26] so i'm sure our MLO is correct [12:27] lool, can you ignore the MLO and just boot with u-boot in qemu? or do you need to simulate exactly? [12:27] it only falls back to NAND [12:27] rcn-ee: I don't think I can boot u-boot directly, no [12:27] rcn-ee: Unless you know how to achieve that? [12:27] well I could put u-boot.bin as MLO, not sure how that'd work [12:28] rcn-ee: But I'd like qemu to be able to load our Ubuntu images [12:28] some users have done it, that's why i ask... (you got to really cut down on u-boot size) [12:28] well perhaps the qemu partition checking code is not the same as the MLO one :-/ [12:28] okay, I was guessing that might be the reason.. it make sense.. [12:29] Texas Instruments X-Loader 1.4.3 (Mar 25 2010 - 09:53:14) [12:29] Reading boot sector [12:29] Loading u-boot.bin from mmc [12:29] U-Boot 2010.03-rc1 (Mar 24 2010 - 15:50:56) [12:29] OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max clock-720Mhz [12:29] http://paste.ubuntu.com/401137/ [12:29] lool, ^^^^ [12:29] ogra: ok, thanks [12:29] (i recompiled x-loader today, but its identical to the archive version (built from package) [12:32] lool, found this.. http://www.omappedia.org/wiki/E-MMC_boot#eMMC_RAW_boot_Procedure_for_ZOOM3 SYS_BOOT defines what x-loader boots from first.. [12:33] it's zoom, so not 100% the same as beagle.. [12:33] crap, nevermind, that's just a hardware config boot option.... [12:34] Texas Instruments X-Loader 1.4.3 (Mar 24 2010 - 21:16:42) [12:34] Reading boot sector [12:34] Loading u-boot.bin from mmc [12:34] U-Boot 2010.03-rc1 (Mar 24 2010 - 15:50:56) [12:34] OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max clock-720Mhz [12:34] OMAP3 Beagle board + LPDDR/NAND [12:34] here another one with both versions from the packages [12:35] rcn-ee: Well that's relevant [12:36] rcn-ee: I'm personally more suspicious that QEMU doesn't set SYS properly than x-loader misparsing my part data [12:36] kinda, it'll help find the boot variable in x-loader.. [12:36] I was trying to write that to SD to actualy try [12:36] lool, x-loader seems to be very fragile wrt partitioning [12:37] which is very odd [12:37] i wouldn't be suprised, x-loader needs a specific partition setup, any variations and it fails... [12:37] i'm struggling with image building on exactly that problem atm [12:37] rcn-ee, exactly what i found here [12:37] and it needs to be copied on the filesystem as the vers first file as well [12:38] *very [12:38] yeap... that's one reason i've always ignored it on the wiki's... the factory version is usually good, so no reason to upgrade.. ;) [12:38] else it wont load [12:38] well, i have seen beagles with empty NAND [12:38] in which case you *need* a working MLO [12:38] yeap, that does happen... [12:39] (my xm is empty) [12:39] and i also want our images to install the same MLO into NAND that we just used to boot the image [12:39] i.e. i want to be sure that NAND has something that works [12:39] that makes sense... it would almost be easier to have a seperate recovery image.. [12:39] which is why i build -xloader.bin and MLO in the package [12:40] usually an ubuntu image should be used for recovery [12:40] we use that scheme in x86 so i want to use it on arm as well [12:41] one image for all.. but it sounds like you got MLO and u-boot working.. omap on qemu is still a virgin setup... [12:44] the one case that problems might arrise, is when a overo or igepv2 user boots with that image.. i don't remember if MLO detects hardware, or is hardware specific... [12:50] MLO is definately HW specific [12:52] ogra: i don't think it's a good idea to install our MLO in NAND [12:52] lool, x-loader.bin should go to NAND [12:52] not MLO :) [12:52] 13:39 < ogra> and i also want our images to install the same MLO into NAND that we just used to boot the image [12:52] I don't think that's a good idea [12:53] indeed [12:53] the x-loader.bin should go to NAND but its the same binary after all, MLO just adds a header [12:53] (I don't think we need to touch people's NAND unless that's what they want explicitly) [12:54] ogra: I'm not convinced we want to install a x-loader which defaults to MMC in NAND [12:54] I don't think we need touch their x-loader at all in fact; there are multiple nice mechanisms to boot from SD on beagle already: boot.scr, or user button [12:58] ogra: You might want to build two x-loaders then: one which loads from MMC by default and one which loads from NAND by default [13:03] i know when a user picks up one from digikey the board will boot from x-loader into a working u-boot enabled for boot.scr... it's just some of the early xm's and demo units don't have nand setup... [13:04] or the ones you bricked :) [13:04] exactly.. or the ones with broken nand... ( i got one here) [13:04] yeah, i trashed my revB many times already [13:04] laughs, i have a user who wants to fit a 500mb xfce karmic image in 128 mb of nand..... ;) [13:05] compress harder :) [13:05] ogra: how close are we to an image? I am trying to decide if we should start compiling in all the OMAP drivers into the kernel till we get the image going... [13:05] that's going to be my response.. and strip everything.. [13:06] amitk, note very close yet, i'm struggling with the bootloader restrictions for partitioning ... but i hope to have that solved latest tomorrow [13:06] amitk, if we want to use the kernel for more than beagle i'd suggest being as modular as you can [13:06] if we dont care for other HW but beagle for now, go for it [13:07] i'll keep testing with all my boards, i know a user with an overo that should be able to verify th eimages too.. [13:07] ogra: I'd like other OMAP3 HW to just run on the same kernel (because it can!). But we can always go back to being modular once the images work [13:08] amitk, can we ? (does time permit) [13:08] we'Re late in the cycle and the kernel didnt even see much testing yet [13:08] i expect a ton of bugs to show up in the next weeks [13:08] do you expect to have time for debugging module issue additionally ? [13:10] rcn-ee: Do you know how Angstrom builds the x-loader for their image? [13:10] cause that one works [13:10] it tries MMC and succeeds [13:10] lool, its the same upstream so it must be a config change they do, ask _koen_ in #beagle [13:10] cool... they might have one or two external patches. [13:11] ah [13:11] i thought they use sarkoman's branch plainly [13:12] just one, but only a name thing... recipie is here: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/x-load/x-load_git.bb [13:12] they are using shaid: dee19371019ef67cb1f6491ef91791b12feda3f2 it might not be top of tree... [13:13] they are also using their special 4.3.1 compiler... === hrw|gone is now known as hrw [15:54] hrm [15:55] so i have the script using fdisk up to a point that u-boot gets properly loaded but MLO doesnt [15:56] I tried using parted, but it's not accepting the high-head and high-sector values I'm passing :-/ [15:56] well, i resorted to fdisk for now [15:56] but MLO isnt behaving [15:57] u-boot and kernel are though [16:02] ogra: omap3 card partitioning? [16:02] image partitioning [16:02] ogra: in OE we have a script for it [16:02] card partitioning is trivial :) [16:03] sure [16:10] ogra: does sfdisk work for it? [16:11] might [16:11] I've used that in the past for some automated partitioning, however I was using real disks at the time, so I'm not sure off the top of my head [16:11] seems that if nothing else, you could use it on a loopback device [16:15] no, cant [16:15] thats the big prob with our image builders :) [16:15] no root [16:15] being able to loop mount would make the whole task trivial [16:17] the way you have to do it is to create an image, partition that, and then dd the partition contents in place [16:20] * ogra curses ... [16:20] so using dd with a blocksize always gets the sizes wrong ... using dd with a blocksize of 1 byte gets everything right but takes hours [16:22] i wonder if we cant just dd the MBR in front of the image instead [16:42] bah [16:43] now i have one script that makes MLO work but fails with a bootsector error to load u-boot and one script that uses MLO from NAND but loads u-boot fine [16:43] sigh [16:44] god, thats annoying [16:49] I'm having some strange problems with networking in qemu. Networking is apparently fine in qemu, i.e. apt-get and such works from the guest ubuntu. I start a ssh-server in guest and I'm able to connect and log into it from the host. However I cannot get any output! [16:49] tcpdump on both host and guest reveals that packages are being sent from host to guest, but not the other way around [16:51] If I kill the ssh session on the guest, all the ssh's output arrives on the host ssh client === hrw is now known as hrw|gone [17:52] lool, why did we always do these complicated image buildscripts, cat'ing partition images to an mbr.img file that holds the mbr is so much less effort [17:52] especially since you have the sizes available from the files === GrueMaster1 is now known as GrueMaster [19:12] Is there anyone else that have struggled with ssh connection into a qemu arm versatile session? I think I have wasted a couple of hours trying to figure it out. [19:13] The network is fine, so it's something particular which happens with the ssh server on the guest. [19:13] (I'm running lucid ubuntu-minimal from rootstock on the guest) [19:27] * nosse1 gives up his endeavour to have more than 80x24 in qemu === hrw|gone is now known as hrw [20:03] ogra: binary blobs versus code? [20:57] lool, binary blobs ? [20:58] dd if=/dev/zero of=mbr.img bs=1 count=512 [20:58] parted -s mbr.img mklabel msdos [20:58] cat $IMAGE >>mbr.img [20:58] something like that [21:04] I think I have found a bug, but I dont know if its something that needs fixing [21:05] file it :) [21:05] If you make a lucid ubuntu-minimal image, run it with qemu and install openssh-server, ssh to localhost does not work [21:06] The question is if this is a ubuntu issue or a qemu specific "feature" [21:19] OK, the bug is recreated from scratch using only rootstock and qemu [21:19] Where should I file it? To what package/module? [21:19] rootstock for now, i'll check where it actually fits later [21:21] Quick question before I file: Is rootstock limited to ARM targets? [21:22] currently it is [21:25] ogra: how is it going? [21:25] amitk, bad [21:26] amitk, the CHS requirement for fat partitions is biting me badly [21:26] Hmpf [21:26] right, the 255 blah blah [21:26] yeah [21:26] doing that for images is very painful [21:26] but i'll figure it out [21:27] *somehow* [21:27] you mean you can't partition automatically? [21:27] i can partition, but either x-loader or u-boot dont get loaded [21:28] worst case i'll just assume that the NAND setup just works, but i'D prefer to not do that [21:29] I'm running a patched version of rootstock. asac pointed me to a patch a couple of days ago. The diff I have sais 31_30.diff. [21:30] What is that? I should put a reference to it in the bugreport I think [21:30] thats to enable lucid on a karmic build system [21:30] "Version 31 of the karmic version of rootstock"? [21:31] You will understand that? [21:33] nosse1, yes :) [21:33] ogra, thanks [21:47] Submitted [21:48] thnaks