[14:55] <ogra> NCommander, uboot executes a bootscript which scans all supported boot devices for a boot script ??
[14:55] <ogra> why would it not look for uImage instead
[14:55] <NCommander> ogra, how do you set a kernel command line then?
[14:56] <ogra> in the uboot environment
[14:56] <NCommander> As it stands, you can't access the uboot envirionment from userland
[14:56] <NCommander> There's no SPI-NOR driver in the dove kernel
[14:56] <ogra> how do you know ?
[14:57] <ogra> have you tried the distro kernel that only exists since two days yet ?
[14:57] <NCommander> I haven't tried that one, I had tried the previous binaries from Marvell and our kernel team
[14:57] <NCommander> Even if we could access u-boot directly, I still think being able to execute boot scripts is a better way to go as then we have more control of the boot process
[14:57] <Meizirkki> anyone here familiar with android hacking?
[14:58] <ogra> right, please work with the kernel team so they get tests from you and you get all options you need
[14:58] <NCommander> Meizirkki, try #android-dev
[14:58] <ogra> i assume you worked through uboot-tools by now and know how they work ?
[14:58] <NCommander> ogra, I'm not getting why we want to touch uboot's enviornmental variables directly if we have a better way to control the boot process
[14:58] <NCommander> ogra, right, uboot-envtools, and uboot-mkimage
[14:58] <ogra> s/tools/envtools/
[14:58] <Meizirkki> NCommander, thanks, i'm looking for anyone who might have some knownledge about the android-on-ubuntu
[14:59] <ogra> i dont get why you want to move into grub1 hell
[14:59] <Meizirkki> that's why i was asking here
[14:59] <NCommander> ogra, grub1 hell?
[14:59] <ogra> grub and its menu.lst was always very error prone, if you can avoid such a setup you should
[15:00] <NCommander> How is it more error prone then just poking the u-boot variables from RAM?
[15:00] <ogra> NCommander, your boot proposal doesnt tell anything about the image layout or your plans
[15:00] <NCommander> And you still need to be able to load the command line from the boot device
[15:00] <ogra> u-boot should try to load ext2 and fat formats, at /boot.scr and /boot/boot.scr
[15:00] <ogra> can you make a decision for one here
[15:01] <ogra> (prferably the latter)
[15:01] <NCommander> No, it should support both
[15:01] <NCommander> Having a separate /boot should be supported, as well as just one whole root partition
[15:01] <ogra> you dont want to have /boot.scr
[15:01] <NCommander> If /boot is a separate partition, when u-boot mounts it, its going to see it as /boot.scr
[15:01] <ogra> there is nothing that indicates a separate /boot
[15:02] <ogra> please properly write down how your image will look like first
[15:02] <ogra> and how the installed system will look in the end
[15:02] <ogra> make sure your setup supports what you lay out
[15:03] <ogra> *then* add the noce to have stuff like separate /boot
[15:03] <ogra> or /boot.scr
[15:03] <ogra> the layout should be the first thing you describe
[15:03] <ogra> so people know how it looks like
[15:04] <ogra> you should also remove all the mentioning of imx51 in the spec ... its a bit confusing
[15:09] <NCommander> ogra, amended.
[15:11] <ogra> so *will* you have a separate /boot or will you *not* have a separate boot ?
[15:11] <ogra> your spec doesnt say that
[15:11] <ogra> "Normal vmlinux and initrds will continue to exist in /boot alongside the uImage/uRamdisk. "
[15:11] <ogra> thats definately something you should quickly tell the kernel team
[15:12] <ogra> since they just changed everything to *not* produce vmlinuz
[15:12] <ogra> please work closer with them, they are depending on your input
[15:12] <NCommander> ogra, both are supported
[15:13] <ogra> no
[15:13] <NCommander> no?
[15:13] <NCommander> We don't want to support /boot as its own partition?
[15:13] <ogra> i was commenting on vmlinuz
[15:13] <NCommander> oh
[15:13] <NCommander> argh, i talked to rtg on this yesterday, and no one said a thing
[15:14] <ogra> what did you tell him to do ?
[15:14] <NCommander> ogra, I had asked him on the status of packaging after being pointed at him by bjf
[15:14]  * NCommander sighs
[15:14] <ogra> they are modifying the deb package this moment to build uImage
[15:14] <ogra> after the deb package sat in NEW since yesterday night
[15:14] <NCommander> ogra, this is also why I wanted to use flash-kernel, so nothing would have to change elsewhere in the postinsts, and update-initramfs
[15:15] <ogra> please coordinate with them on all the kernel stuff
[15:15] <ogra> they will happily give you what you need if you actually tell them
[15:16] <ogra> vmlinuz is surely not needed at all if the deb can spit out uImage at build time
[15:16] <ogra> and you save hacking to convert vmlinuz
[15:16] <NCommander> ogra, hrm, fiar enough, I was thinking about having the uImage made as the postinst rule
[15:16] <ogra> why if the package can just use make uImage
[15:17] <ogra> what would you use vmlinuz for at all ?
[15:28] <ogra> NCommander, so what i would like to see in the spec is: the current livefs we build will use a partitioning scheme like: ... blah ...
[15:28] <NCommander> ogra, I didn't know we could make uImage, I didn't realize Marvell added that target
[15:28] <ogra> the installed system will default to a extX single partition setup (or will have /boot separated by default) etc etc
[15:29] <ogra> i'm not talking about kernels yet
[15:29] <ogra> i want to know what you are building and how the installed system looks like with the selected defaults
[15:30] <ogra> and en explanation why you decided for the layout
[15:30] <NCommander> ugh
[15:30] <NCommander> This may be a stupid question
[15:31] <NCommander> But is an ext4 filesystem compatible w/ ext2 once extents are enabled?
[15:31] <ogra> i.e. "the installed system will use a two partition layout by default because we want to support the default used ext4 filesystem for the rootfs but uboot does not support that for /boot"
[15:31] <NCommander> I remember reading that once you enable extents or do a full format, ext2 compatbiility flies out a window
[15:31] <ogra> something like that
[15:31] <NCommander> Ugh
[15:31] <ogra> its your project
[15:31] <NCommander> Let me update the spec to reflect that
[15:31] <NCommander> ogra, yes, I know
[15:31] <ogra> make a proper design, describe it and give reasoning for the decisions
[15:32] <ogra> for both the livefs and the resulting installation
[15:32] <NCommander> ogra, doing so now
[15:32] <ogra> ok
[15:32] <ogra> take your time
[15:33] <ogra> i assume it will take a day writing that up properly unless you have it prepared already
[15:33] <NCommander> ogra, I do have it prepared (I wrote up my ideas on the internal wiki, but I didn't quite get the right level of detail when I started writing :-))
[15:34] <ogra> right, flesh it out, compare pro and con fo different designs and give an explanation why you decided for a particular design
[15:35] <NCommander> ogra, *nods*
[15:35] <NCommander> ogra, great, I see having to tweak partman in my future though :-/
[15:35] <NCommander> the fun just never ends
[15:36] <ogra> you could decide for a single partition ext3 setup
[15:36] <ogra> that limits the changes
[15:36] <ogra> u to you
[15:36] <ogra> *up
[16:24] <ogra> tlee2, hey am i just mailing with you ?
[16:24]  * ogra just notices you are here, we could chat quicker than by mail
[17:13] <tlee2> Orga, hi, yes, that's me.
[17:14] <ogra> cool ! :)
[17:14] <ogra> great to see you here
[17:15] <tlee2> Thx
[17:15] <ogra> amitk, ogra@dove:~$ uname -a
[17:15] <ogra> Linux dove 2.6.31-rc5 #1 Tue Aug 18 17:39:23 CEST 2009 armv7l GNU/Linux
[17:15] <ogra> amitk, meet tlee2, he is working on doves at marvell :)
[17:16] <NCommander> hey tlee2
[17:16] <ogra> tlee2, amit is one of our arm kernel guys
[17:16] <tlee2> nice to meet you Amitk.
[17:16] <ogra> amitk, so make uImage in the package tree gets me proper booting images
[17:17] <ogra> ready to change the packaging :)
[17:17] <amitk> tlee2: hi there
[17:17] <NCommander> tlee2, you won't happen to do anything w.r.t. to uboot on the dove?
[17:18] <amitk> ogra: awesome. So we'll changes the configs to create uImages instead of zImage
[17:18] <ogra> yeah
[17:18] <ogra> perfect
[17:18] <tlee2> what's w.r.t?
[17:18] <NCommander> tlee2, with respect to :-)
[17:19] <tlee2> Well, I am new to this ...  Ok, I use the uboot.  Sometime, I build it too.
[17:19] <tlee2> Do u need anything on uboot for Dove.
[17:19] <tlee2> Wow, your uImage is newer than mine.....
[17:19] <NCommander> tlee2, working USB support would be nice :-/
[17:20] <tlee2> Need to upgrade mine now.
[17:20] <ogra> tlee2, i just built it some mins ago :)
[17:20] <NCommander> The last drop I got still didn't have it working (I'm not sure if SATA works as I lack the connector cable which I need to try and get today)
[17:20] <ogra> from the latest merged tree from our kernel team
[17:21] <ogra> they are working on getting a proper kernel package together atm, these are needed for the live images
[17:21] <tlee2> I use sata and NFS from uboot.  They are faster, have not try usb from uboot yet.
[17:21] <ogra> well, we traget live images, so everything has to be on the same media
[17:21] <ogra> NFS is no option for that
[17:22] <NCommander> tlee2, so SATA support works, that's a win
[17:22] <ogra> cool would be if uboot could run what it finds on a USB key or SD card
[17:22] <tlee2> SATA already work.
[17:22] <NCommander> ogra, that's my plan
[17:22] <ogra> then you get into a live image and run a normal install to SATA
[17:22] <NCommander> ogra, the bootscript is going to iterate through all USB/SATA devices on start
[17:22] <NCommander> ogra, like the beagle, with different devices
[17:23] <ogra> right
[17:23] <NCommander> ogra, that's why a boot script is loading from the partition and not mucked w/ uboot-envtools
[17:23] <ogra> i was trying to explain to tlee2 what we are actually targetting
[17:23] <NCommander> ah
[17:23]  * NCommander goes back to writing
[17:23] <ogra> yeah, if your writeup is done we can just point people there ;)
[17:23] <NCommander> ogra, its getting there
[17:24] <ogra> tlee2, NCommander is the michael i was CCing in the mail before ... he does the dove images
[17:24] <NCommander> tlee2, is there a method to load a u-boot into RAM without flashing it? I got a set of steps, but it just caused the board to reset, and I don't have a JTAG flasher or equivelent to recover from a bad flash if that happens
[17:24] <NCommander> tlee2, nice to meet you
[17:25] <tlee2> Nice to meet you NCommander.
[17:26] <tlee2> One few other board, there are way to load uboot to RAM from SATA.  I have not try that on Dove.
[17:27] <tlee2> I don't have to change the uboot on my boards.  And I have ice.  :-) Sorry.
[17:27] <NCommander> tlee2, well, I read the technical specifications we got, and I know the BootROM can load u-boot from NAND, SATA, NOR, and serial
[17:27]  * ogra knows the beagleboard does that from SD ... so its easy to replace uboot there 
[17:27] <NCommander> ogra, no SD support in Marvell's u-boot
[17:27] <NCommander> (yet)
[17:27] <ogra> yeah
[17:27] <NCommander> tlee2, but I haven't managed to figure out how to flip the boot device
[17:27] <NCommander> ogra, I'm not sure its targetting to exist or not)
[17:28] <ogra> ??
[17:28] <ogra> can you rephrase that ?
[17:28] <NCommander> ogra, there's currently no SD/MMC support in uboot (the entire subsystem is missing). I'm not sure if we're excepting it or not to exist
[17:29] <ogra> we need one, SD or USB ...
[17:29] <ogra> i personally dont care which one :)
[17:29] <NCommander> Right, and I know USB is supposed to be coming
[17:29] <ogra> right
[18:02] <tlee2> When are we going rebuilding the karmic with vfp compiler?     How long do u think it will take?
[18:03] <ogra> as soon as the new build machines are in place
[18:03] <ogra> the HW is there but afaik we're waiting for a chunk of new disks
[18:03] <tlee2> The build machine is Dove, imx51 or Beagle?
[18:04] <ogra> currently the older marvell boards (v5) new ones will be imx51
[18:05] <ogra> our IS team lokes to use ubuntu on the build machines, imx51 is the system we have stable images for since last release ... we're hoping to upgrade everthing to dove next cycle
[18:05] <ogra> s/lokes/likes/
[18:08] <tlee2> which v5 board r u using?
[18:08] <tlee2> 78k?
[18:08] <ogra> i dont know the exact model actually
[18:08] <ogra> but yeah, i think its 78xx something
[18:09] <ogra> i'm luckily not working in the datacenter ;) i just use it
[18:09] <tlee2> I see, just remotely....   Cool.
[18:13] <jmc93739653> I know this is a little off topic, but does  anyone know if Freescale & Pegatron are still on target for a i.MX515 netbook release in the early fall?  It would be _perfect_ for Linux & ARM development, but I haven't heard anything since January.  128 MB on a Nokia N800 is a bit cramped (and gcc's -Os flag doesn't like to play nice for me).
[18:14] <jmc93739653> I've only heard of, and possibly found a single JPG of a Babbage Board, so I'm presuming it's several thousand per dev-kit.  A consumer i.MX515-based rig on the other hand....quite compelling.
[18:15] <ogra> there is a company selling an imx51 development board for $750, i sadly lost the link
[18:15] <ogra> its largely the thing that will go into the pegatron netbooks
[18:16] <jmc93739653> ogra: That alone is a lead to work off of.  If I find it, I'll pastebin or tinyurl it and paste it here.
[18:17] <jmc93739653> ogra: I had some extra money in January when the i.MX51 line was announced, I would have bought one right then and there. 1000 MHz ARMv7A?  Yes, please.
[18:18] <suihkulokki> ogra: presume you are talking about genesi
[18:18] <ogra> yeah, right
[18:19] <ogra> there are nettops coming from pegatron too but i dont know when they will go into mass production
[18:19] <jmc93739653> suihkulokki: Genesi finally released the 515 boards?  They had their i.MX projects using Rev B Beagle Boards, last I heard.
[18:19] <ogra> if you want something *Really powerfull* you wait for the marvell dove boards though ;)
[18:21] <tlee2> ogra, the 78k build machine you are using can be use to build and test vfp code.   Is there any issue with that?
[18:21] <ogra> outdated kernels
[18:22] <tlee2> 78k kernel is check in to the kernel.org already.
[18:22] <suihkulokki> jmc93739653: no idea if they are really released but they have it on their website
[18:22] <jmc93739653> Are the Marvell Dove boards based on their Sheeva SoCs?
[18:23] <ogra> jmc93739653, better :)
[18:23] <jmc93739653> ogra: and Marvell's asking price ? (and the system RAM capacity?)
[18:24] <ogra> no idea yet but ram i have seen was 512M
[18:25] <jmc93739653> ogra: Nice. :) Is it true Ubuntu had a custom ARM-based motherboard built loaded to the gills with 2 GB of RAM, and clustered them into a build farm?
[18:26] <ogra> heh, who told you that ?
[18:28] <jmc93739653> ogra: honestly, I don't even remember.  I thought I read it on something like LinuxDevices.com, but at the time I was scanning 7000 tech stories a day from XML feeds.  The story was centered about a company which aided in the manufacture of embedded development boards, but was starting to center upon customized variants of their primary products.
[18:28] <ogra> well, its not true
[18:29]  * lool returns and waves
[18:31] <ogra> lool, have you see the dove kernel in NEW ?
[18:31] <ogra> the naming is borked again :/
[18:33] <jmc93739653> ogra: damn!  Oh well, dreams are nice.  I'd be OK with QEMU, but it seems like no matter what x86 CPU I throw at it, ARM emulation is, let's say, sub-optimal.  I thought x86-64 would speed things up given better register parity between the ISAs, but I was wrong.  (A Diablo N800 running on QEMU-10.5 is not nearly as agile as I was hoping.)
[18:33] <ogra> yeah, qemu arm emu is even worse on amd64
[18:34] <ogra> thats why i only built the qemu-arm-static packge for i386
[18:35] <ogra> it has massive issues with chroots on amd64
[18:36] <ogra> (assuming you have seen https://wiki.ubuntu.com/ARM/BuildEABIChroot )
[18:36] <jmc93739653> OK.  Thank you for the heads-up.  Has anyone been able to determine why amd64 causes so many issues?  Toolchain or code-base maturity/testing/deployment-base advantages of i386 over amd64?
[18:37] <ogra> i stopped looking at qemu-system-arm ... userspace syscall translation is so much faster for the purposes i need qemu for
[18:38] <jmc93739653> ogra: Yes, I have.  I was going to tackle the EABIChroot walk-through later this week in some spare time.  I have amd64 Karmic Alpha 4 installed, but if 32-bit from top to bottom pays dividends, I'll leave idealistic ISA daydreams at the door, and go back to i386.
[18:38] <ogra> heh
[18:39] <jmc93739653> ogra: karmic over jaunty for ARM-emulation purposes?
[18:39] <ogra> yes
[18:39] <ogra> qemu 0.11 is a real imrpovement
[18:40] <jmc93739653> Cool.  The qemu versioning and the addition qemu-arm-static lead me towards karmic.  (I could have sworn I say a qemu-arm-static package for amd64.  Well, that's hay-fever season and extra-drowsy antihistamines for you....)
[18:41] <jmc93739653> s/say/saw
[18:41] <ogra> no, there is none
[18:41] <ogra> i had one of the hacked up 0.10 in my PPA
[18:42] <lool> ogra: Did you give a heads up to kernel team WRT kernel name?
[18:42] <ogra> lool, yes, rtg knows my concerns about the header names
[18:43] <ogra> fls is also being worked on i was told
[18:43] <ogra> *fsl
[18:43] <ogra> NCommander, http://people.canonical.com/~ogra/arm/dove/
[18:43] <ogra> there is the uImage of my testbuild from todays branch
[18:44] <ogra> (note the deb there is old and outdated)
[18:48] <jmc93739653> ogra: I never checked the PPA, truth be told. ARM eabi-chroot and QEMU packaging, maintenance and modification are several of your core competencies, I'll take your word over my suppositions. :)
[18:49] <ogra> heh, i never touched qemu before this release cycle :)
[18:49] <ogra> but right, i'm focused on it since a few months
[18:50] <ogra> mainly for image builders for hardware we dont support ... the arm community is still to small
[18:51] <jmc93739653> ogra: Sweet.  All I've done with qemu source is alter the partition table parameters for the Nseries tablet emulation to enable Diablo compatibility.  (I had fun.  amd64's weaknesses hopefully explain why the ARM emulation ran so poorly.)
[18:52] <ogra> i'm currently banging my head against the missing sched_getaffinity() syscall in qemu-arm-static
[18:53] <ogra> it makes mono installations fail in the images
[18:56] <jmc93739653> A 45nm, 3.0 GHz Core 2 Duo with a 65 watt thermal budget should not be beaten out by a 90nm, 2.0 Pentium-M for qemu emulation.
[18:56] <jmc93739653> ogra: do you have any URLs for the issue reports handy?  I'll grep around launchpad all the same.  Am I right in assuming sched_getaffinity() is a QEMU syscall, rather than a libc6 or libpci-dev system-call?
[18:57] <suihkulokki> ogra: feel free to send me a patch once you've implemented the syscall in qemu linux-user :)
[18:58] <ogra> its a libc syscall that needs to be translated between the two arches
[18:59] <ogra> suihkulokki, i have a patch that apprently idles around in the suse packages since ages
[18:59] <ogra> they didnt bother to every send it upstream it seems
[19:00] <ogra> sadly i havent mad it work yet ... it applies fine to 0.11 and the "unsupported syscall" messages goes away
[19:00] <ogra> but the mono cil assembly installation still doesnt finish
[19:01] <ogra> suihkulokki, http://paste.ubuntu.com/255278/
[19:02] <ogra> in case you hve any idea for improvements
[19:05] <suihkulokki> ogra: I guess you'll want to look at the definition of cpu_set_t
[19:05] <ogra> good idea
[19:06] <jmc93739653> Does any one know if using x86-32's PAE tanks userspace qemu performance?
[19:06] <suihkulokki> ogra: also qemu-arm -strace ./foo and comparing it to strace qemu-arm ./foo gives usually good hints where the syscalls go wrong
[19:06] <ogra> but not today anymore ... i'm on the kbd since 13h without break ... thanks for the suggestion though i'll dig into it tomorrow
[19:08] <ogra> i really dont get why suse didnt contribute it upstream though ... i pulled that out of their 0.9 package
[19:08] <suihkulokki> at least suse is sending most of their patches upstream
[19:09] <ogra> well, that one not :) and it seems it has been a prob in maemo and scratchbox since ages
[19:10] <ogra> though i doubt there are actually many people running mono on n8x0's :)
[19:11] <jmc93739653> ogra: I'm hesitant to run Python apps on an N800 :)
[19:11] <jmc93739653> Anyways, thanks everyone for your patience and time. My apologies for the rather daft questions.
[19:11] <ogra> py is fine though from a design perspective it was intended to run cross arch
[19:12] <ogra> mono only grew suport for non x86 later
[19:12] <ogra> anyway, its getting late, i'm working way to long already and will call it a day now
[19:13] <jmc93739653> ogra: Take care, again, thank you.
[19:13] <ogra> :)
[21:03] <Madsy> I followed the RootFromScratch article to setup Ubuntu for QEMU, but the emulated system crashes right away. I'd really appreciate some pointers on what the cause might be.
[21:04] <Madsy> Here's my log from running the build-arm-rootfs script, with some of the overly verbose package info omitted: http://gist.github.com/169920
[21:37] <lool> Madsy: Looks like the script assumes presence of /etc/init.d/loopback which is not there for you
[21:37] <lool> Madsy: perhaps it works with karmic?
[21:38] <lool> Madsy: Either file a bug or talk to ogra here
[21:43] <Madsy> lool: I'll give the updated rootstock script a try first. Thanks for replying.
[21:57] <Madsy> Gah, I feel stupid. I didn't remember that both QEMU and the kernel parameters take "friendly" values for sizes. I forgot an 'M'
[22:45] <hammad> hi, i want to build a portable media player using the arm processor, is there somwhere you can point me to for guidance to start me on it.
[22:45] <hammad> it is just n idea right now
[22:46] <hammad> m planning on having a touchscreen and a camera and bluetooth for i/o
[23:46] <hammad> with respect to the above query, if anyone can help me out, please contact me at: hammad.fauz <at> gm ail <dot> com