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