=== ScriptRipper_ is now known as ScriptRipper
=== WyrM is now known as WM
=== WM is now known as drwyrm
=== drwyrm is now known as WyrM
=== ApOgEE- is now known as ApOgEE
[10:48] <ogra> cbrake, looks like your host system is missing proper timezone configuration (the script tries to determine your TZ from /etc/timezone of the host)
[10:50] <ogra> cbrake, as a quick fix run: sudo dpkg-reconfigure tzdata ... before you run the script
[14:15] <cbrake> ogra: yup, that worked -- thanks
[17:44] <cbrake> is there a standard way for making modifications to an embedded Ubuntu rootfs?
[17:45] <cbrake> I need to add some files for serial console, and set up the default networking
[17:45] <ogra> untar it, make your changes, tar it again ;)
[17:45] <cbrake> obviously, I can hack these files into the tarball, but wondering how support for various macnhines is done
[17:45] <ogra> as long as its config changes that will work just fine
[17:45] <persia> cbrake, As much as possible, we attempt to make the system able to handle all machines.
[17:46] <persia> So, for instance, the kernel and udev should be populating the devices you need, and you should be able to pass kernel command-line options for the serial console.
[17:46] <persia> Networking is a bit trickier: mac-based DHCP is a handy way to go.
[17:47] <cbrake> persia: I can get kernel messages out the serial port with kernel command line, but it does not start a getty on the serial port unless I do https://help.ubuntu.com/community/SerialConsoleHowto
[17:48] <ogra> yeah
[17:48] <persia> Hrm.
[17:48] <ogra> the rootfs build script only rolls a rootfs and adds a set of defaults ubiquity would add otherwise
[17:48] <persia> I wonder if there's a sane model for having that enableable on boot.  Might be handy for server folk as well.
[17:49] <ogra> there isnt without creating the file in event.d
[17:49] <ogra> i could add a switch to the script, but that still leaves the serial options
[17:49] <ogra> i dont want to crowd the script with to many options
[17:49] <ogra> i.e. serial speed etc that should be set in the ttyS0 file
[17:49] <persia> Oh, right.
[17:50] <persia> I was sorta-kinda-hoping there would be some way to feed it without hardcoding, for general deployment.
[17:50] <ogra> but i surely can add a switch that at least creates it with a bunch of defaults
[17:50] <cbrake> I'm coming from the Openembedded world where the concept of machine support is very prominant, so trying to get re-aligned ...
[17:51] <ogra> yeah, ubuntu is rather focusing on "as broad as possible" support
[17:51] <persia> cbrake, Yeah, it's a different way of looking at things.  We tend to focus on having a (mostly) general solution, rather than lots of machine-specific versions.
[17:51] <ogra> which indeed leaves off a lot of optimization
[17:52] <ogra> but gets nearly anyone the option to run it
[17:52] <ogra> (as long as your arch matches the minimal reqs ... i.e. ARMv5 in jaunty, ARMv6+ in karmic etc)
[17:53] <cbrake> interesting, so ARMv5 is only for jaunty
[17:53] <ogra> yeah, karmioc will do v6 ... likely vfp and NEON
[17:53] <cbrake> my default installs are running at 380MB -- is there any way to trim that down?
[17:54] <ogra> well, its not OE :)
[17:54] <cbrake> nod :-)
[17:55] <ogra> you can cut down by ripping out packages indeed
[17:55] <cbrake> so is that typically done by apt-get remove after the system is booted?
[17:55] <cbrake> or is there a way to remove packages when generating the rootfs?
[17:55] <ogra> no
[17:55] <ogra> after booting
[17:56] <cbrake> ok, thanks for all the help
[17:56] <ogra> unless you build a qemu image first, trim that, loop mount it and tar it up
[17:56] <ogra> the prob is that you cant just chroot into the rootfs ... you need a vm
[17:56] <cbrake> yes, qemu is pretty useful for that vs the target machnine
[17:56] <ogra> but the script has an option to build a qemu only image
[17:57] <persia> Well, unless you're building the rootfs on an armel system :)
[17:57] <ogra> which you then can boot in qemu and trim
[17:57] <ogra> oh, indeed
[17:57] <ogra> if you have powerful arm HW thats indeed the quicker option
[17:58] <persia> well, you might have to go through the rootfs game to bootstrap, but once there...
[17:59] <ogra> indeed ... you wouldnt use the script at all then
[18:02] <persia> Why not?  Wouldn't the script speed the bootstrap?
[18:04] <ogra> it would still run qemu
[18:05] <persia> Well, yeah, but you have to do the initial boot somehow, unless debootstrap just works on the BSP.
[18:06] <ogra> oh, right
[18:36] <Martyn> re
[18:37] <Martyn> ogra : have you ever had this error pop up? (gcc 4.2)   LD      init/built-in.o
[18:37] <Martyn>   LD      .tmp_vmlinux1
[18:37] <Martyn> `.cpuexit.text' referenced in section `.ARM.exidx.cpuexit.text' of arch/arm/mach-realview/built-in.o: defined in discarded section `.cpuexit.text' of arch/arm/mach-realview/built-in.o
[18:37] <ogra> nope
[18:37] <persia> Martyn, You mentioned yesterday that you found a power issue with idle_pm vs. kernel_idle.  I just wanted to poke you to file a bug about that (as I hear the kernel *should* do the right thing with kernel_idle)
[18:39] <Martyn> persia : As soon as we're done with the tests (Fri) I'll do so.
[18:39] <persia> That soon?  Excellent!  Thanks.
[18:39] <Martyn> persia : More things have been discovered since yesterday, that may be errata in the i.mx51 and RealView_Cortex_A9
[18:39] <persia> I always like it when it's a hardware problem :)
[18:39] <Martyn> it's a very high priority now
[18:40] <Martyn> well, it's more than a hardware problem.  If its a fundamental design issue in the SoC, it's something my company will have to carefully watch for as we create ours.
[18:40] <Martyn> power domain issues are so.. fucking.. finicky
[18:41] <Martyn> ogra : Thoughts on booting SMP -- right now, I'm having a whale of a time getting the Cortex-A9MP kernel to go SMP, because for some reason ARM expects the bootloader (u-boot in this case) to hold the non-main cores in WFI (I use WFINE)
[18:42] <Martyn> ogra : however, the other cores never get the software interrupt they need to get going . and even THEN .. the WFI resumes right where it left off .. in the bootloader.
[18:42] <Martyn> I think it's the kernel itself that should hold the other processors back in WFI .. right?
[18:42] <Martyn> so that when it restarts the PC's of the other cores are pointed at kernel code .. not bootloader code.
[18:43] <ogra> hmm, amitk might be able to tell
[18:44] <Martyn> *nod8
[18:44] <Martyn> My boss made nosies at ARM about getting us a babbage2
[18:45] <Martyn> ogra : Question though .. in order to unify the Ubuntu/ARM universe, are we standardising around RedBoot?
[18:45] <Martyn> or was RedBoot just convenient for the Babbage?
[18:45] <Martyn> OR .. are we shifting to UEFI?
=== cbrake is now known as cbrake_away
=== Nicke_ is now known as Nicke