[01:09] <MrCurious> hah! google.com/+ interactive tour blew up my X session on ubuntu 11.04 pandaboard :)
[01:09] <MrCurious> google + will blow your mind (or your embedded systems mind)
[03:25] <lilstevie> is anyone around that can tell me how the initial boot stuff works with the preinstalled image
[03:26] <lilstevie> with my device I found nvflash to have a 4GB filesize upload restriction
[03:33] <persia> Maybe.  What part don't you understand?
[03:34] <lilstevie> well, 1 is triggering it on another device
[03:34] <lilstevie> 2 is a bit more difficult to explain
[03:34] <persia> Another device?  Do you mean different partitions?
[03:34] <persia> (or rather, different /dev/ nodes)
[03:34] <lilstevie> no I mean the transformer rather than panda
[03:35] <lilstevie> :p
[03:35] <lilstevie> I upload an ext4 image
[03:35] <lilstevie> which does not take up all the room it is allocated
[03:37] <persia> Ah, so you want to resize the filesystem on first boot?
[03:37] <persia> Doesn't the transformer have significant internal flash?
[03:38] <lilstevie> yeah 16 or 32
[03:38] <lilstevie> but I am trying to retain enough for the android system to co-exist
[03:38] <persia> Heh, OK.  Ubuntu requires 4GB, and 8 or more is recommended.
[03:39] <lilstevie> well my current image is 4.2GB
[03:39] <persia> Is the transformer capable of booting from alternate media (e.g. SD)?
[03:39] <lilstevie> which is nvflashes max upload
[03:39] <lilstevie> yeah it can, but emmc is soooooo much faster :)
[03:39] <lilstevie> its like an F1 next to a smart
[03:39] <persia> That's fine.
[03:39] <infinity> Sure, but slow installation media isn't the end of the world.
[03:40] <lilstevie> ah installation media :p
[03:40] <persia> In cases where it is possible to boot off removable media OR internal storage, you don't want to do what is done with the panda.
[03:40] <lilstevie> I see
[03:40] <persia> Instead you want to cause booting off the SD to perform an install to the internal media
[03:40] <lilstevie> actually that would be better
[03:40] <persia> (and you want to give the user choices to set up dual-boot or completely reformat and just run Ubuntu).
[03:41] <lilstevie> providing everyone has µSD
[03:41] <persia> infinity, Were you ever pointed to the branch for that tarball installer ogra wrote?
[03:41] <lilstevie> yeah that does sound nicely
[03:41] <lilstevie> nicer*
[03:41] <infinity> persia: Nope, but we'll get it all public RSN.
[03:41] <persia> Oh well.
[03:41] <infinity> persia: Especially since it'll find its way into an official image soon. :P
[03:42] <persia> lilstevie, So, there exists an installer that does precisely what you want.  Unfortunately, it's not being developed transparently, so you have to wait, or reinvent the wheel :(
[03:42] <lilstevie> eh :(
[03:42] <infinity> (Not that you have to wait long, mind you)
[03:42] <lilstevie> I am not reinventing something when it does not need to be
[03:42] <lilstevie> infinity: define not that long :)
[03:42] <infinity> There's no reason it's not public except a bit of laziness.  We have the technology to fix that.
[03:43] <persia> I'm not sure there is a technical solution to ogra being lazy, really.
[03:43] <lilstevie> heh
[03:43] <infinity> Like, you're not waiting for weeks/months on process or anything, just waiting hours/days on people being poked sufficiently violently.
[03:43] <lilstevie> heh
[03:43]  * persia has been waiting months
[03:43] <lilstevie> well it would make things easier
[03:43] <infinity> persia: I poke harder.
[03:43] <lilstevie> flash kernel, insert SDCard, make the choises
[03:43] <persia> True.  I've only tried cajoling, shaming, and bribing.
[03:43] <lilstevie> does this installer have the option for a virtual keyboard
[03:43] <infinity> Sharp sticks.
[03:43] <StevenK> Bribery doesn't work
[03:44] <infinity> lilstevie: Virtual keyboard is mostly up to your FS image, not the installer.
[03:44] <persia> lilstevie, From my experience with my dynabook, it's more 1) tell the bootloader to boot from SD, 2) insert SD card, 3) make the choices.
[03:44] <infinity> lilstevie: Well, "installer" here meaning "tiny initramfs shim".
[03:44] <persia> Kernel should come from the archive.
[03:44] <persia> StevenK, It's worked for me many a time.  Corruption and graft are rife.
[03:44] <lilstevie> infinity: heh, cause that is somethign of a must for me, while the dock is there, it is not always going to be
[03:44] <lilstevie> some people don't own the keyboard dock
[03:45] <infinity> lilstevie: I'll keep that in mind as I generalise this.  Since I suspect that virtual keyboards and early boot will NOT get along.
[03:45] <infinity> lilstevie: We might want to generalise something for phone-like hardware interrupt hooks.
[03:45] <persia> lilstevie, Aren't there some function buttons on the tablet?
[03:45] <infinity> (things like "press the home button to select installation to media X", etc)
[03:46] <lilstevie> persia: power, vol-up vol-down
[03:46] <persia> We can work with that.
[03:46] <lilstevie> hc devices have no other GPIO buttons
[03:46] <infinity> Yeah, if there's any hardware button at all, we can do clever things.
[03:46] <lilstevie> I have a bit more to work with on the SGT
[03:46] <persia> vol-up/vol-down to select.  Power to choose.  Hold power for hard-reset.
[03:46] <lilstevie> I have that plus a touchstrip
[03:46] <infinity> For some value of "we" that won't be me, unless I have devices to muck with.  But I could proof-of-concept the idea on my N900 or G1 or something.
[03:47] <persia> Do you have a working kernel for that?  I'd *really* like to upload it.
[03:47] <persia> infinity, If you can get something working for the n900, the kubuntu-mobile folk would love you.
[03:47] <lilstevie> persia: for which ?
[03:47] <persia> They've a wiki page with all sorts of annoying mucking about currently.
[03:47] <persia> lilstevie, SGT.
[03:48] <persia> We were talking about it a couple weeks ago, and you ran into a touchscreen issue, and I hadn't heard from you since.
[03:48] <lilstevie> persia: oh the issue is much bigger than we though
[03:48] <infinity> persia: My N900 is pretty much Just Another armel Buildd right now, so yeah, I'm happy to screw with it as a dev device again.
[03:49] <lilstevie> 2.6.32 is the only kernel with a working tsp at the moment, and one of the utouch team has found a bug
[03:49] <persia> apachelogger, Notice the volunteer for the installer work above
[03:49] <lilstevie> but I have been a little preoccupied with the transformer for the time being
[03:50] <persia> Oh, annoying.  Can I have a kernel with broken touchscreen?
[03:50] <persia> We can call that a bug, and fix it later, but we can't fix not having a package once the freezes start.
[03:50] <infinity> Real men ssh to their tablets and phones anyway
[03:50] <infinity> Touchscreens are for the weak.
[03:51] <infinity> (Is the above pretty much proof of all the Maemo work I did for Nokia?)
[03:51] <lilstevie> persia: heh, well bug on which
[03:51] <lilstevie> persia: cause both of them are kinda working
[03:51] <lilstevie> 2.6.35 has a weird issue where clicks are not being interpretted correctly
[03:52] <persia> lilstevie, So, we upload linux-sgt 2.6.35+, and we file a bug "Touchscreen driver is broken".
[03:52] <lilstevie> and 2.6.32 is duplicating the touch frame
[03:52] <infinity> There was a 2 month period or so where neither the hardware OR on-screen keyboards worked on the N9 prototypes. :P
[03:52] <StevenK> infinity: Which gave you what, ssh?
[03:52] <persia> infinity, Isn't that why one has bluetooth?
[03:52] <lilstevie> persia: sure then I can upload one :)
[03:52] <infinity> StevenK: SSH and serial.
[03:52] <persia> lilstevie, That would be lovely!  Put it anywhere, and I'll dig through it for packaging stuff, and stick it in the archive.
[03:53] <lilstevie> persia: source or binary
[03:53] <lilstevie> and we need to mark 2 major bugs :)
[03:53] <persia> Source.  Preferably packaged source :)
[03:53] <persia> That's fine.  Once it's in the archive, we just report them to LP.
[03:53] <infinity> persia: How do you pair a bluetooth keyboard with a host you can't talk to? ;)
[03:53] <lilstevie> 1) TSP, 2) Temp broken command line
[03:54] <persia> infinity, agressive udev rule.
[03:54] <lilstevie> persia: well I have te source up on github if that helps
[03:54] <infinity> persia: I imagine the GUI folks probably pulled such tricks.  I don't touch UI anyway, so whatever.  Serial/SSH are less hassle than poking phones anyway.
[03:54] <persia> Well, kinda.  Are you up for packaging it, or do you need someone else to help with that?
[03:55] <lilstevie> well I have only packed for butchered apt before
[03:55] <lilstevie> so I would need some help :)
[03:55] <persia> infinity, You are my favourite flavour of luddite :)
[03:55]  * persia tries to find jcrigby's handy kernel packaging instructions
[03:56] <infinity> persia: Have you seen how I use computers?  Heck, even my mobile phone is pretty much just a mobile terminal emulator.
[03:56] <lilstevie> do I need to strip the .gitignores?
[03:56] <infinity> persia: X exists to multiplex terminals.  That's it.
[03:56] <persia> infinity, I've seen you use GUI browsers :p
[03:56] <persia> lilstevie, https://wiki.linaro.org/Resources/HowTo/PackageYourOwnKernel
[03:57] <persia> It's not absolutely perfect, but it will get you 95% of the way there.
[03:57] <infinity> persia: I blame that on the fact that HTML5 and Flash and other fancy crap is pretty painful in lftp/w3m/lynx/etc.
[03:57] <persia> If you want a comparison source, take a look at the linux-n900 package: I tweaked a few bits there.
[03:57] <persia> infinity, You just haven't configured your MIME handlers properly then.
[03:58] <infinity> Heh.
[03:58] <persia> lilstevie, Actually, please ignore the hints to add ccache in that HOWTO: I forgot to clear that, and my first upload FTBFS.
[03:59] <lilstevie> heh ok
[03:59] <infinity> If any of the free swf reader libraries were actually usable, I'd totally waste a weekend writing an aalib frontend.
[03:59] <persia> Why aalib?
[03:59] <persia> No reason you can't spawn a useful viewer
[04:00]  * persia fondly remembers web surfing with twm and no internal browser handlers
[04:00] <infinity> Ahh, but if I want to live my life entirely in terminals.
[04:00] <lilstevie> persia: thanks, will get on to that soon :)
[04:00] <persia> There are any number of terminals that can show bitmaps...
[04:00] <persia> lilstevie, If you get stuck or run out of time, let me know, and I'll see what I can do from your git tree.
[04:01] <infinity> Well, I guess with framebuffers being the norm these days.  In my mind, I still live in a "terminal = text mode" world.
[04:01] <infinity> Even if that's almost never true anymore.
[04:01] <persia> But I'd rather if you have time to learn it, as I'd be counting on you to maintain it :)
[04:01] <lilstevie> persia: :) no problems
[04:02] <persia> Cool.  Two more kernels queued :)
[04:02] <persia> Now if only there were documentation on how to create an image with arbitrary kernels and extra driver bits from a published rootfs...
[04:03]  * infinity glares.
[04:04] <infinity> We'll get there.
[04:05] <persia> We're not in a terrible hurry.  The kernels need a preview cycle before any of the product managers are supposed to request an image anyway.
[04:05] <persia> (sometimes people work around that, but it involves bribing the release managers, and it's just easier to wait a few extra months).
[04:05] <lilstevie> heh
[04:05] <infinity> I accept pie.
[04:06] <infinity> And peanut butter cookies.
[04:06] <infinity> I've been trying to get someone to send me homemade peanut butter cookies for months.
[04:07] <lilstevie> I'll accept a job
[04:07] <lilstevie> :p
[04:07] <infinity> I'll give you a job baking me cookies.  That's some corporate synergy right there.
[04:07] <lilstevie> hah
[04:08]  * persia suggests http://www.simplesimonpies.com/ as preferred pie provisioners
[04:08] <infinity> persia: They don't have pumpkin.
[04:08]  * micahg wishes -pie and arm would get along
[04:09] <persia> infinity, You failed to specify
[04:09] <infinity> micahg: We have Top Men working on that bug, apparently.
[04:10]  * persia has lost the site for delivery of peanut butter cookies, unfortunately :(
[04:14]  * micahg wonders if giving infinity pie will get me -pie on arm :)
[04:14] <Martyn> persia : Delivery .. of .. wha?
[04:14] <Martyn> persia : Sign me up.
[04:15]  * Martyn is busy putting in even _more_ patches to u-boot
[04:15] <Martyn> to allow loading configs from disk, with menu
[04:15] <Martyn> approaching syslinux capability now
[04:15] <Martyn> syslinux levels of capability rather
[04:15] <persia> Martyn, We've a temporary issue: simplesimonpies apparently doesn't carry pumpkin, which means we aren't actually arranging a delivery just now.
[04:16] <Martyn> poo
[04:16] <persia> Martyn, Did you see jcrigby's proposal for the configuration file?  He had something that would allow one u-boot compilation per SoC, rather than per-board (at least in theory).
[04:16] <infinity> Not to mention pecan-coconut being an abomination.
[04:16] <Martyn> I did ..
[04:16] <Martyn> persia : It's a ways off though
[04:17] <Martyn> infinity : coconut creme, equally so
[04:19] <persia> Hrm?  I thought it was RSN, for a unified OMAP u-boot.
[04:20] <infinity> persia: I didn't get the impression that it was THAT soon when we chatted about it in Dublin.
[04:20] <infinity> persia: Just a definite "working-toward" thing.
[04:20] <infinity> Which beats "it's on the TODO".
[04:21] <Martyn> yep
[04:21] <Martyn> it _might_ be ready, just after Oneric
[04:21] <rsalveti> GrueMaster: mahmoh: found the issue with pxe
[04:21] <rsalveti> is a bug at the device tree support at u-boot
[04:21] <Martyn> rsalveti: Issue?
[04:21] <Martyn> rsalveti: *perk*
[04:21] <persia> rsalveti, Nice!
[04:21] <Martyn> what happened?
[04:22] <jcrigby> rsalveti, you are my hero!
[04:22] <persia> Martyn, I'm reminded: do you have network and usb gadget drivers for u-boot for your devices?
[04:22] <Martyn> network, yes
[04:22] <Martyn> USB, no (we don't do USB)
[04:22] <persia> Heh, if there's no port, there's no need for the driver.
[04:23] <persia> But if you don't do USB, how do you handle KVM?
[04:23] <Martyn> Well, in-theory- I guess you could put a USB device on a PCIe bus .. but .. um .. yea
[04:23] <rsalveti> jcrigby: hey!
[04:23] <Martyn> persia : We have our own built-in management CPU
[04:23] <rsalveti> the issue is kind of stupid
[04:23] <Martyn> persia : Where we're going .. we don't need .. keyboards: )
[04:23] <persia> Martyn, So only VKVM via IPMI?
[04:23] <Martyn> SOL, yep
[04:23] <Martyn> all out of band
[04:24] <persia> Ah, that works.
[04:24] <rsalveti> jcrigby: common/cmd_pxecfg.c, check function label_boot
[04:24] <Martyn> rsalveti : Looking here too
[04:24] <rsalveti> jcrigby: in the end it tries to set the agv[3]
[04:24] <rsalveti> bootm_argv[3] = getenv("fdtaddr");
[04:24] <rsalveti> and later call do_bootm(NULL, 0, 4, bootm_argv);
[04:24] <rsalveti> so argc is always 4
[04:24] <persia> Most of the implementations I've seen in the past end up wiring something that looks like PS/2 or USB to the HW, but if you don't need that, more power to you (or rather more power saved, really).
[04:24] <rsalveti> even when argv[3] is NULL
[04:25] <rsalveti> so later on u-boot things the ftd file is there, because argc > 3
[04:25] <rsalveti> and tries to use it, and boom, seg fault
[04:25] <persia> Aha!
[04:25] <lilstevie> so, transformer is wifi capable now, but this is far from optimal
[04:25] <Martyn> rsalveti : Oops..
[04:25] <lilstevie> needs a full network block in the wpa_supplicant
[04:25] <lilstevie> no scanning
[04:25] <rsalveti> Martyn: :-)
[04:25] <Martyn> rsalveti : Make sure you tell jason.hobbs@calxeda.com
[04:26] <Martyn> we'll fix it ...
[04:26] <rsalveti> Martyn: sure, cooking a patch now
[04:26] <Martyn> plus it means we need to patch the upstream, again .. *sigh*
[04:26]  * Martyn is on the trail of getting rid of pre-baked configs in configuration.h now
[04:27] <Martyn> since, if everything works according to plan, you'll be able to load the configuration and environment in u-boot from -- an AHCI device (FAT/EXT2,3,4), off the network, off some local flash ...
[04:27] <Martyn> instead of having it all baked in
[04:28] <Martyn> leaving the only thing needing to be baked in .. the order of where to search
[04:28] <persia> Why?
[04:29] <persia> Create a menu that lists the various (detected) options, and whilst it is scanning them, waits for the user to select the preferred one.
[04:29] <persia> if the user completely fails to be paying attention, then fall back to a predetermined order once the scan is complete.
[04:29] <mahmoh> rsalveti: when you have a u-boot with a patched pxe please ping me
[04:29] <rsalveti> mahmoh: in a minute :-)
[04:30] <Martyn> persia : Chicken and egg problem
[04:30] <persia> Martyn, Why?
[04:30] <Martyn> persia : Because even with a timeout, you need to have -some- indication of where to look first
[04:30] <Martyn> since the u-boot environment is coming from there, and not from configuration.h
[04:31] <persia> Martyn, So, as you're doing device discovery, you're prepared to accept an interrupt from console input.  If an interrupt is received, you wait for the user to confirm the list before proceeding.  If no interrupt is received, you go ahead with your prebaked order.
[04:31] <Martyn> persia : Also, u-boot doesn't do detection
[04:31] <Martyn> persia : At least, not _yet_ it doesn't
[04:31] <persia> Fix the yet :p
[04:31] <Martyn> it only detects what you tell it to :)
[04:31] <Martyn> yes yes yes
[04:31] <Martyn> But I'll attack this one (large) problem at a time
[04:31] <mahmoh> rsalveti: in a min.?  I was hoping tmw ;)
[04:31] <Martyn> if I try to patch too much at once, Wolfgang will have kittens
[04:32] <rsalveti> haha
[04:32] <mahmoh> lol
[04:32] <persia> Martyn, So, short term: you tell it to detect foo, bar, baz, and quux in a predetermined order for your hardware.
[04:32] <persia> Then you start constructing a menu whilst it's doing that.
[04:33] <persia> And if the user does something, you let them reorder the sequence before starting the selected config.
[04:33] <persia> If the user is too slow, you proceed with your initial intentions.
[04:33] <Martyn> Yep, that's more or less what's in store
[04:33] <Martyn> although the menu generation code is brand-spanking new
[04:33] <Martyn> and it's really designed to handle PXE stuff
[04:33] <Martyn> however, things are progressing nicely
[04:34] <persia> Ah, good.  Your initial announcement made me think it was just going to check foo, bar, baz, and quux in compile-time order, and boot the config found first.
[04:34] <Martyn> persia : Well that's what _will_ happen in the first pass
[04:34] <persia> (which config might include a menu, etc.)
[04:34] <persia> Awwww.....
[04:34] <Martyn> however, from whatever source it finds first, it will load the menu
[04:35] <Martyn> and so it's not any worse than, say, syslinux booting from EXT2, or a CD, or whatever
[04:35] <Martyn> And thanks to the AHCI support, it just may .. MAY .. be possible for me to boot a CD on ARM .. wouldn't that be something?
[04:35] <Martyn> Just in time for the whole CD technology to go obsolete, of course .. but .. :)
[04:35] <infinity> I'm going to pretend you didn't say that.
[04:35] <persia> I suppose.  Can't we do that today with EHCI and USB CD drives?
[04:36] <infinity> If someone asks me for ARM ISOs, I intend to stuff my fingers in my ears and scream "la la la, I can't hear you".
[04:36] <rsalveti> mahmoh: http://people.canonical.com/~rsalveti/pxe/3/u-boot.bin
[04:36] <Martyn> infinity : I -promise- you the format of an ARM CD will be something simple and sane
[04:36] <persia> infinity, There is a reason why the provided images on cdimage.ubuntu.com are supposed to be less than 700MB compressed.
[04:36] <persia> infinity, Something about tradeshows and pressing costs...
[04:36] <Martyn> infinity : Such that you won't have to bend your tools
[04:37] <infinity> Martyn: Good, I don't like bending my tool.
[04:37] <infinity> Err.
[04:37] <Martyn> infinity: But ARM is a good place to break clean away from CD's
[04:37] <persia> Martyn, they have already been warped beyond recognition, in ways that may significantly improve the situation for other architectures.
[04:37] <Martyn> infinity: There is absolutely NO reason that we shouldn't be booting from good, standard 1G memory sticks
[04:37] <infinity> Martyn: Yeah, I tend to boot from USB or SD on all my non-ARM hardware too.
[04:37] <Martyn> I have put in an order for 500 ubuntu, oneric logo'ed usb keys for Orlando to give away
[04:37] <persia> Martyn, trade shows...pressing costs...
[04:38] <infinity> (But in that case, it often involves pretending it's a CD, which is VILE)
[04:38] <Martyn> infinity: It shouldn't ... at least not on ARM
[04:38] <Martyn> infinity : AFAIK, the ARM installer is nothing more than the standard net installer really..
[04:38] <persia> infinity, Hrm?  Even most of my powerpcs can boot from USB if I glower at them enough.
[04:38] <Martyn> bunch of seeds and a repository .. which is a far easier layout than the usual CD layout
[04:39] <Martyn> no ISO9660 to worry about
[04:39] <infinity> persia: I was pointing a finger at x86 in that case.  PPC is much saner, as are all the arches that grew up in the UNIX world.
[04:39] <persia> Martyn, So, there are *four* installers currently provided (well, three and the one expected later this week).
[04:39] <Martyn> yeah, noticed that
[04:39] <persia> infinity, I don't believe I have any remaining x86 devices that can't boot USB, but then I'm kinda rough on hardware.
[04:40]  * Martyn got his hands on a Nufront machine .. cute laptop, but FLIMSY
[04:41] <Martyn> someone out there MUST be making a better laptop with the Cortex A9
[04:41] <persia> Martyn, All of them are based on debian-installer in one way or another.  We have the base d-i environment (sometimes called "alternate" or "netboot"), the ubiquity wrapper for running it in a live environment, jasper which does just enough to launch oem-config, another d-i wrapper, and another initramfs shim (yet to be named), which again does just enough to run oem-config (at least, as last I heard it described).
[04:41] <Martyn> Although I did see a Kal-El based prototype here in Austin that -was- seeeeexxxy ... looked like a thin thinkpad .. ran 2Ghz, had 3Gb of RAM
[04:42] <rsalveti> mahmoh: let me know if it works for you
[04:42] <rsalveti> jcrigby: just sent you the patch
[04:42] <Martyn> had one hell of a pretty screen (1400x900) too
[04:42] <rsalveti> Martyn: also included jason
[04:42] <Martyn> thanks!
[04:42] <Martyn> he'll get to it tomorrow when he gets into work
[04:42]  * Martyn is doing OpenMPI work this weekend
[04:43] <Martyn> making sure the whole OpenMPI set works ..
[04:43] <rsalveti> great, panda booted with PXE :-)
[04:43] <rsalveti> and working fine
[04:43] <Martyn> then I need to convince all -you- folks to compile and put OpenMPI 1.5.3 into the repository
[04:43] <rsalveti> awesome
[04:43] <rsalveti> jcrigby: then we just need to fix the mac address problem with panda
[04:43] <Martyn> rsalveti : Awesome...
[04:43] <Martyn> rsalveti : Doesn
[04:43] <rsalveti> and it'll be done :-)
[04:43] <Martyn> Doesn't the panda use a USB adapter?
[04:44] <Martyn> so you have to get USB up first, then the network adapter, then get all the PXE stuff up?   Ever fun.
[04:44] <rsalveti> Martyn: it uses smsc95xx, usb hub and usb eth
[04:44] <Martyn> yeah.. thought so
[04:44] <rsalveti> the kernel is setting a unique mac address using the die id
[04:44] <mahmoh> rsalveti: small problem
[04:44] <rsalveti> we just need to use the same code at u-boot
[04:44] <Martyn> I'll be -much- happier when more SoC vendors get off their asses and integrate a NIC right into the AMBA bus like we do
[04:44] <rsalveti> mahmoh: didn't work?
[04:44] <mahmoh> rsalveti: it works, now I have more work to do!  I was hoping for a few days off ;)
[04:45] <mahmoh> rsalveti: want a bug for it?
[04:45] <rsalveti> mahmoh: ;-)
[04:45] <Martyn> Buah-ha-ha-ha!
[04:45] <rsalveti> mahmoh: don't need, just sent the patch to jcrigby
[04:45] <mahmoh> rsalveti: ok but we should track the work ...
[04:45] <rsalveti> hm, maybe a bug to update the package before the 07 release...
[04:45] <rsalveti> mahmoh: yeah, please fill a bug :-)
[04:45] <persia> Bah.  Filing bugs is for when you *don't have the fix ready.
[04:46] <rsalveti> then we can patch the package
[04:46] <rsalveti> and properly track it
[04:46] <mahmoh> rsalveti: against lp:u-boot?
[04:46] <rsalveti> mahmoh: against package u-boot-linaro
[04:47] <rsalveti> you can also link at u-boot-linaro project
[04:47] <rsalveti> mahmoh: let me know the number and I'll take care of it
[04:47] <mahmoh> shortly
[04:50] <mahmoh> rsalveti: u-boot-linaro ?
[04:50] <rsalveti> mahmoh: yup
[04:51] <mahmoh> rsalveti: I'll file it there then you can add the other one?
[04:51] <rsalveti> mahmoh: sure
[04:51] <mahmoh> sweet, thx
[04:56] <Martyn> rsalveti : Hey, mail me the patch as well -- martin@calxeda.com
[04:56] <rsalveti> Martyn: sure, 1 sec
[04:56] <Martyn> (yeah, different style address to everyone else ... early hire hath it's privs ... and besides, who wants to type martin.bogomolni@ all day?)
[04:57] <rsalveti> Martyn: sent
[04:57] <Martyn> danke
[05:02] <mahmoh> rsalveti: is this panda specific?  I'm guessing not.
[05:02] <rsalveti> mahmoh: nops
[05:02] <rsalveti> but you'll only find this issue if you build with CONFIG_OF_LIBFDT
[05:03] <mahmoh> rsalveti: all yours, thx all!  https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/808612
[05:03] <ubot2> Ubuntu bug 808612 in u-boot-linaro "pxe fails after loading kernel and initrd" [Undecided,New]
[05:03] <rsalveti> mahmoh: great, thanks
[05:03] <mahmoh> np
[05:06] <mahmoh> nighty, nite
[05:06] <mahmoh> and good work, I appreciate it (everyone)
[09:05] <stm__> hi all
[09:05] <stm__> can any one point me how to build a rootfs using rootstock for custom kernel
[09:15] <stm__> iam following steps mentioned at here to build rootfs
[09:16] <stm__> http://elinux.org/BeagleBoardUbuntu
[09:16] <stm__> i have a doubt in
[09:16] <lag> stm__: For which board?
[09:16] <stm__> sudo ./rootstock --fqdn omap --login ubuntu --password temppwd --imagesize 2G \ --seed wget,nano,linux-firmware,wireless-tools,usbutils --dist natty --serial ttyO2 \ --components "main universe multiverse" \ --kernel-image http://rcn-ee.net/deb/natty/v2.6.39-x1/linux-image-2.6.39-x1_1.0natty_armel.deb
[09:16] <stm__> pandaboard
[09:17] <stm__> what changes i have to do in the above command
[09:17] <stm__> i have bulded uimage
[09:17] <lag> I don't think you need to make any changes?
[09:17] <lag> What's wrong with the image that's produced?
[09:17] <stm__> of xenomai patched kernel 2.6.37.6
[09:18] <stm__> no , i have to build rootfs for the custom kernel
[09:19] <stm__> which patched with xenomai alreay
[09:20] <stm__> how should i use that kernl to build the rootfs
[09:54] <lag> stm__: Sorry, I didn't know you replied
[09:54] <lag> stm__: Please use my nick when replying
[09:54] <stm__> ok
[09:54] <lag> stm__: The rootfs is not built for the kernel
[09:54] <lag> stm__: Once you have a rootfs you can just install a new kernel into it and it'll just work
[09:55] <lag> stm__: Is your kernel in *.deb or uImage form?
[09:55] <stm__> lag: mkdir /tmp/xeno cd /tmp/xeno wget http://www.codesourcery.com/sgpp/lite/arm/portal/package7851/public/arm-none-linux-gnueabi/arm-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 tar -xvjf arm-2010.09-50-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 export PATH=/tmp/xeno/arm-2010.09/bin:$PATH git clone --depth 1 git://git.xenomai.org/xenomai-2.5.git git clone --depth 1 --branch for-ipipe-2.6.37-arm git://git.xeno
[09:56] <stm__> lag: this is the procedure i got the patched kernel and
[09:56] <stm__> builded u Image
[09:57] <stm__> lag: how should i build the rootfs using this uImage
[09:58] <lag> stm__: You don't
[09:58] <lag> stm__: I'm assuming you're using an SD card?
[09:58] <stm__> lag: yes
[09:58] <stm__> iam using sdcard
[09:59] <lag> Mount the SD card
[09:59] <stm__> Llag: i placed uImage and mlo and uboot.bin in fat16 partion
[10:00] <stm__> sorry
[10:00] <lag> That's it then
[10:00] <stm__> lag
[10:00] <lag> Boot it
[10:00] <lag> All you have to do is replace the uImage with your own kernel
[10:00] <stm__> placed modules on ext partion
[10:00] <lag> Great
[10:00] <lag> Done - boot it
[10:01] <stm__> lag: its not booting
[10:01] <lag> Then there's a problem with the kernel
[10:01] <lag> Or u-boot
[10:01] <lag> Does u-boot boot?
[10:02] <stm__> if dide not use update initramfs then its givng me root partion is not mounted
[10:02] <stm__> u-boot
[10:03] <lag> Paste me your output
[10:03] <stm__> lag: if i done update initramfs
[10:03] <lag> @ paste.ubuntu.com
[10:03] <stm__> ok
[10:16] <stm__> lag:http://paste.ubuntu.com/641780/
[10:18] <lag> stm__: Can you paste your u-boot variables (printenv)
[10:18] <lag> stm__: Did you back-up the old kernel? Does that still work?
[10:18] <stm__> lag: yes i backuped
[10:19] <stm__> In:    serial                                                                    Out:   serial                                                                    Err:   serial                                                                    Hit any key to stop autoboot:  0                                                 Panda # printenv                                                                 bootcmd=if mmc init ${mmcdev}
[10:19] <stm__> sorry
[10:20] <stm__> bootcmd=if mmc init ${mmcdev}; then if run loadbootscript; then run bootscript;i bootdelay=3
[10:20] <stm__> bootcmd=if mmc init ${mmcdev}; then if run loadbootscript; then run bootscript;i bootdelay=3                                                                      baudrate=115200                                                                  loadaddr=0x82000000                                                              console=ttyS2,115200n8                                                           usbtty=cdc_acm
[10:21] <stm__>          mmcdev=1                                                                         mmcroot=/dev/mmcblk0p2 rw                                                        mmcrootfstype=ext3 rootwait
[10:23] <stm__> lag: here is the printenv
[10:23] <stm__> http://paste.ubuntu.com/641786/
[10:26] <stm__> the board booting up with the old kernel nd with  this bootargs
[10:28] <lag> It may just be a serial issue
[10:28] <stm__> you mean ttyO2
[10:28] <lag> In your rootstock command you had ttyO2, whereas in u-boot is says ttyS2
[10:28] <lag> The kernel could actually be running just fine
[10:32] <stm__> lag: but the rootstock created images or configs related to kernel 2.6.38.
[10:33] <stm__> but my kernel is 2.6.37.6
[10:33] <stm__> i have tried changing in bootscr file
[10:33] <stm__> ttyo2
[10:34] <stm__> Is this might be because of configs the boot program uses during booting
[10:38] <lag> Mount the card again and provide me with `ls /etc/init`
[10:39] <lag> From <mnt_point>/rootfs/
[10:43] <lag> stm__: It's not ttyo2, it's ttyO2
[10:50] <stm__> lag:yes
[10:58] <stm__> lag: http://paste.ubuntu.com/641802/
[10:58] <stm__> the init contails different configs
[11:02] <lag> Are you sure this is the rootfs you built with rootstock
[11:02] <lag> Unless I am mistaken, you are missing the serial init script
[11:03] <lag> I see tty[1,2,3,4,5,6], but no ttyO1
[11:04] <lag> stm__: Paste me your boot.scr
[11:05] <lag> stm__: And try issuing this in u-boot: setenv console ttyO2,115200n8
[11:05] <lag> Then type boot
[11:05] <stm__> lag: ok
[12:11] <stm__> lag: http://paste.ubuntu.com/641839/
[12:11] <stm__> here is the log
[12:11] <stm__> it seems i have some problem
[12:12] <stm__> i can able to login through console
[12:12] <lag> Did you change the boot.scr?
[12:20] <stm__> lag: no actually last time i used the mlo and uboot.bin from ubuntu10.10 builin binaries
[12:20] <stm__> but now i canged the mlo and uboot.bin
[12:21] <lag> Well for some reason your boot.scr is no longer being successfully read
[12:21] <stm__> i mean i builded mlo and uboot.bin
[12:24] <stm__> lag: how should i know that the problem
[12:30] <brendand> does anyone know if a simple USB stick would suffice to alleviate the performance issues associated with using SD as the main storage on the pandaboard?
[12:30] <lag> It's hard to judge
[12:30] <brendand> i.e. is the problem with flash or SD
[12:30] <lag> Firstly make sure it's still there and readable
[12:30] <lag> And that you haven't change it in any way
[12:31] <brendand> i don't actually need that much storage space but would rather not have all the lag
[12:42] <stm__> lag: how can i make the initrd.img-2.6.38-8-omap to uinitrd
[12:45] <lag> http://elinux.org/BeagleBoardUbuntu#U-Boot_uImage_and_uInitrd
[12:45] <lag> stm__: Google really is your friend
[12:46] <stm__> hmm . iam sorry
[13:10] <persia> brendand, It depends on the USB stick.  There are USB sticks that are faster than some SD cards, but flash connected to USB isn't that different from flash connected to MMC connected to USB, and there's plenty of USB sticks that are implemented as USB to MMC to flash anyway (I have at least one where you can see the microSD through the plastic, but it's firmly glued in).
[13:11] <brendand> persia - that's a whole can of worms
[13:12] <persia> brendand, The big win with rotary disks or fast SSD is twofold: 1) they tend to have cache RAM, often with advanced precaching algorithms, and 2) they tend to be turned for non-sequential reads.
[13:13] <persia> Whereas most flash is tuned for sequential reads, as the presumed use cases are things like "store media", "stream media", "transfer some files", etc.
[13:14] <brendand> persia - from a previous life i'm all too aware of that :)
[13:15] <brendand> i once tested a 32GB Panasonic SDHC card which was designed for HD camcorders
[13:15] <brendand> but when you tried random access operations on it...
[13:16] <persia> Then you understand precisely why running an operating system from SD isn't precisely fast.
[13:16] <brendand> yes
[13:17] <brendand> so i guess my safest bet is a proper usb rotary disk drive
[13:17] <persia> Or fast SSD, if you have some extras laying about :)
[13:18] <brendand> i don't want to spend $100 for 1TB of storage i don't need
[13:18] <brendand> that seems to be the smallest you can get in most shops these days
[13:18] <brendand> probably looking online might do it
[13:25] <mahmoh> brendand: what board are you using?
[13:25] <brendand> mahmoh - panda
[13:43] <andreas_bos1> hallo zusammen
[13:44] <persia> Good morning.
[13:45] <LPhas> hello, is there a way to INSTALL ubuntu on a pandaboard using a small (<=2gb) sdcard for boot and a USB pendrive for root? i manage to do it with archlinux and gentoo but i can't figure a way to do it with ubuntu
[13:47] <mahmoh> LPhas: yes, you can specify your root=/dev/sda2   or similar on the kernel command line (assuming you have your root fs on the the first USB stick attached/detected) or install to the USB stick
[13:47] <LPhas> mahmoh, ok i know how to boot with root on a usb stick, but i don't know how install root on a usb stick
[13:48] <persia> LPhas, The documentation for that is not yet ready (as we're just finishing making it simple).
[13:48] <LPhas> i do not have any sdcard > 2gb
[13:48] <mahmoh> LPhas: you can use the new netinstaller for the insall,
[13:48] <mahmoh> install
[13:48] <LPhas> mahmoh, let see
[13:48] <mahmoh> or you can copy what you have over to the USB stick
[13:49] <persia> Be aware that the netinstaller is only available for the development release right now: if you want a production install, you'll want the store&copy solution.
[13:49] <LPhas> mahmoh, were can i find the netinstaller image for omap4?
[13:50] <mahmoh> LPhas: http://ports.ubuntu.com/ubuntu-ports/dists/oneiric/main/installer-armel/current/images/omap4/netboot/    from  https://wiki.ubuntu.com/ARM/OMAP
[13:51] <mahmoh> LPhas: note the partitioning caveat!
[13:52] <LPhas> yep reading it
[13:53] <LPhas> how do i use these images? i guess that uInitrd, uImage, boot.scr goes on the usual boot partition
[13:53] <LPhas> but the boot.img* file where it goes?
[13:54] <mahmoh> LPhas: boot.img contains the all of them, if you're using then separately you won't need them
[13:54] <LPhas> ook
[13:54] <mahmoh> ^them^it
[13:55] <LPhas> so basically i put the files in the boot partition in the sdcard, plug the usb stick, start installation and install / on sdcard
[13:55] <LPhas> ehm on usb
[13:55] <LPhas> but if i must put these files on the sdcard
[13:55] <LPhas> and then repartition sdcard
[13:56] <LPhas> i mean.. this sound strange
[13:56] <mahmoh> LPhas: install / on USB stick, no?  The quickest way would be to just copy the partition you have over to the USB stick, it depends on what your goal is I guess?
[13:56] <persia> LPhas, You can partition the SD card *first*, and then copy in the files you need.  This avoids repartioning.
[13:57] <mahmoh> LPhas: you'll be using the SD card to boot (like a bios) then handing over the root fs to the kernel on the USB stick
[13:57] <persia> Um, no.
[13:58] <LPhas> mahmoh, yeah, this i get and it's basically what i do with gentoo
[13:58] <persia> If we're looking at a BIOS model, it's bios+bootflash accelerator.
[13:58] <LPhas> it's the installation process that bothers me
[13:58] <LPhas> well, let make some experiments, i will be back
[13:58] <mahmoh> LPhas: good luck
[13:59] <mahmoh> persia: excuse my sloppy example ;)
[13:59] <persia> Excused.  I just think it's important to be correct when drawing parallels, as the details can cause confusion later.
[14:00] <persia> Err.  s/correct/precise/ (yes, I'm guilty too)
[14:00] <mahmoh> persia: fair
[14:01] <LPhas> isn't there something missing? like MLO?
[14:01] <mahmoh> you can use the same one that's already on your SD
[14:02] <LPhas> the one i just deleted?
[14:02] <persia> LPhas, good catch.  There's one in the boot.img files (just loop-mount one).
[14:02] <mahmoh> oops
[14:02] <LPhas> (na, joking i made a backup)
[14:02] <persia> NCommander, Any reason not to expose MLO as an available netboot download option?
[14:03] <mahmoh> LPhas: people claim that if you don't write the MLO first to a clean boot partition it may not boot, fyi
[14:04] <ogra_> persia, not really, beyond "we have never done it before"
[14:04] <LPhas> also u-boot.bin
[14:04] <ogra_> yeah
[14:04] <ogra_> can you file a bug against debian-installer ?
[14:05] <persia> ogra_, That's because most of the netinst targets have SPL in flash, and we rely on vendor SPL.
[14:05] <ogra_> persia, nope, thats just because we always built mini isos in the past and sold them as netinst ;)
[14:06] <ogra_> with the exception of versatile where we only wanted a kernel :)
[14:07] <LPhas> to use the img* instead is ony dd if=img of=device ?
[14:07] <ogra_> yes
[14:11] <LPhas> the installer look a beutyful
[14:12] <LPhas> beautyful
[14:14] <persia> ogra_, Erm, no.  See http://ports.ubuntu.com/ubuntu-ports/dists/oneiric/main/installer-powerpc/current/images/powerpc/netboot/
[14:14] <persia> That has kernel, initrd, and yaboot.
[14:14] <persia> But it *doesn't* have OF.
[14:17] <LPhas> mahmoh, ok now i'm officially confused. i'm at this point http://img233.imageshack.us/i/screenshot2fy.png/
[14:18] <LPhas> now i think that the correct way of doying it is to create a partition for / on the usb stick
[14:18] <LPhas> and a partition for /boot on the SDcard
[14:19] <persia> LPhas, You want /boot on USB as well: there's a utility called flash-kernel that will extract stuff from /boot and stick it in the FAT partition on the SD card.
[14:19] <ogra_> persia, i'm tsalking about arm
[14:19] <persia> (well, you could also put /boot on *another* partition on the SD card, if you prefer, but that's just for fun)
[14:19] <LPhas> persia, ok and i'm supposed to run it when?
[14:20] <persia> LPhas, The installer will run it automatically as part of the install, and it will be run automatically whenever you install a new kernel.
[14:20] <LPhas> ok
[14:20] <mahmoh> LPhas: so yo don't have to have boot separate though, just make sure you create a fat32 partition on the MMC/SD and make that bootable too
[14:20] <LPhas> oh
[14:20] <persia> ogra_, Architecture doesn't matter.  Even for ARM targets where we use vendor SPL, the current stuff is fine.
[14:21] <LPhas> so the note about partitioning in the guide refers to that
[14:21] <mahmoh> and I assume you have sda #2 as  /  since I cannot see it
[14:21] <persia> ogra_, And for targets for *any other* architecture where we wanted to use our SPL, we'd need to do the same.
[14:21] <LPhas> and i have to create a separate /boot partition on the usb drive or can i just do only one partition for / (and another for swap maybe)
[14:21] <persia> LPhas, You can get by with just the one partition if you like.
[14:21] <ogra_> still, i was referring to arm and the fact that we never provided actual netboot images
[14:22] <mahmoh> swap is a nice thing on the USB stick if you don't mind the usage
[14:22] <persia> ogra_, Wasn't there some netboot images that worked with Freescale redboot for the Babbage?
[14:22] <LPhas> i can buy another 8gb card for 4 euros
[14:22] <ogra_> persia, yes, mini isos
[14:23] <persia> Swap on flash is bad for the flash, whether it's USB or not.
[14:23] <ogra_> same goes for omap3
[14:23] <persia> For omap3, I thought we always wanted our own u-boot.
[14:23] <persia> Anyway, if we used vendor SPL on the babbage, then the ancillary files would have worked without needing to be the mini ISO.
[14:23] <ogra_> we have (had) mini isos for beagle
[14:24] <ogra_> in lucid ...
[14:24] <persia> Yes, but those contained the SPL.
[14:25] <LPhas> "No mount point is assigned for the fat32 file system in partition #1" and this message should means that i've done correctly, am i right?
[14:25] <persia> LPhas, Yes.
[14:27]  * mahmoh1 has personality problems for 60 mins ...
[14:27]  * persia waits for bzr
[14:31] <rsalveti> mahmoh1: were you able to test the netboot image with pxe?
[14:33] <mahmoh1> rsalveti: yes, booted and installed fine with a tweek - we'll need to setup kernel_ram and initrd_ram addresses manually for now unless you specify it in the boot.scr or uEnv.txt - I'll throw in a bug for it
[14:33] <mahmoh1> tweak
[14:34] <rsalveti> mahmoh1: I believe it should be fine to have that values as default at boot cmdline for panda
[14:34] <mahmoh1> rsalveti: yeah, all the other boot options have addresses assigned, I think it was an oversight
[14:34] <rsalveti> mahmoh1: yeah, open a bug, and we'll see what to do :-)
[14:35] <mahmoh1> but that's the only thing I think needs changing
[14:35] <LPhas> what's the default video driver used by ubuntu in omap4?
[14:35] <mahmoh1> thx
[14:35] <persia> Anyone have any suggestions for descriptions for MLO and u-boot.bin?
[14:35] <LPhas> persia, x-boot image, u-boot image?
[14:35] <ogra_> first stage bootloader and second stage bootloader ?
[14:35] <persia> LPhas, The default is just framebuffer.  TI has a PPA with powervr drivers that many people use.
[14:36] <persia> LPhas, Not very informative, but maybe :)
[14:36] <mahmoh1> rsalveti: panda specific bug? u-boot-linaro-panda?
[14:36] <LPhas> xboot image (second stage bootloader), u-boot image (first stage bootloader)
[14:36] <rsalveti> mahmoh1: u-boot-linaro package :-)
[14:36] <persia> ogra_, The issue there is that there is too much terminology using that structure.  The "S" in SPL stands for "second", but that's MLO.
[14:36] <mahmoh1> ack
[14:36] <rsalveti> but yeah, specific to panda
[14:37] <LPhas> persia, powervr are the closed source driver, am i correct?
[14:37] <ogra_> persia, well, if you call hard wired ROM code FPL indeed
[14:37] <persia> LPhas, Yes.
[14:37] <persia> ogra_, Most folk seem to do so.  I'm in agreement with you, but then I don't come from an embedded background.
[14:37] <ogra_> (which i wouldnt)
[14:38] <ogra_> well, i cant make up better descriptions :)
[14:38] <LPhas> is there a repository with binary omap-gstreamer that you know about?
[14:38] <ogra_> not for natty
[14:38] <ogra_> unless TI recently uploaded something
[14:40] <LPhas> ogra_, can i compile from sources i guess
[14:40] <LPhas> my whole point would be have pandaboard playback hd video with gstreamer
[14:40] <mahmoh1> rsalveti: https://bugs.launchpad.net/ubuntu/+source/u-boot-linaro/+bug/808815   thx
[14:40] <ubot2> Ubuntu bug 808815 in u-boot-linaro "pxe missing kernel_ram and initrd_ram defaults" [Undecided,New]
[14:41]  * persia decides to go with "Mini Loader for OMAP Beagle" and "Universal Bootloader for OMAP Beagle" (switching Beagle/Panda when I get to that file)
[14:41] <ogra_> persia, http://omappedia.org/wiki/Bootloader_Project
[14:41] <ogra_> what would "mini loader" mean ?
[14:42] <persia> That's apparently what "MLO" abbreviates.
[14:42] <ogra_> no
[14:42] <ogra_> its Mmc LOader
[14:42] <persia> Your internet has a different selection of wild guesses than mine.
[14:42] <persia> Ah, cool.  I'll use that.
[14:42] <LPhas> persia, i would mention uboot and xboot in the description, when a first got my hands on the pandaboard one thing i didn't figure out in the first momento was "what *CENSORED* is uboot?"
[14:43] <ogra_> persia, according to the doc above x-loader is 1st stage by their definition
[14:43] <persia> I know.  Didn't I say there was wild inconsistency in the nomenclature?
[14:44] <ogra_> well, its conform with my assumption, no inconsistency at all :)
[14:44] <mahmoh1> bbib
[14:51] <persia> ogra_, The issue is that there is the IPL, SPL, TPL, QPL, PPL, HPL sequence, which implies cardinality which fails to match your and my prior understanding of bootloaders.
[14:57]  * persia sadly watches bzr push 73K at 9kB/s for a 3019 character patch
[15:03] <persia> Or maybe it's lying, as that ought to have been done by now :(
[15:04] <LPhas> who did design the ascii installer for the omap4 netinstall? he's a genius
[15:04] <LPhas> i love it
[15:05] <persia> LPhas, The Debian Installer team.
[15:06] <LPhas> oh, i don't love it anymore
[15:06] <LPhas> it was a short infatuation
[15:07] <persia> What happened?
[15:10] <LPhas> i don't like debian :p
[15:13] <persia> Well, Ubuntu is heavily based on Debian: I hope your dislike doesn't translate (and maybe that we can erode some of it).
[15:14] <LPhas> yeah, ubuntu is basically debian, but they are intended for different porpuses. even if ubuntu is not my favourite distribution i can manage to live with it (an i used and loved it heavily in the past) but debian i can't stand it
[15:15] <persia> Intended for different purposes?
[15:15] <LPhas> yeah i mean
[15:16] <LPhas> as i see it, ubuntu is intended mainly for desktop/workstations
[15:16] <LPhas> while debian is mainly used for servers
[15:17] <LPhas> when i go for "software selection" should i include also "basic ubuntu server" or if i install "ubuntu desktop" there's no need for that?
[15:17] <GrueMaster> Nah, more like Debian is geared towards the hacker and Ubuntu is geared more towards the user.
[15:18] <GrueMaster> What are you going to do with your install?  That should give you a direction on what task to select.
[15:18] <LPhas> GrueMaster, mmh i don't really share your point of view. there are more "hackish" distribution like gentoo (urgh) or archlinux (which i prefer)
[15:18] <GrueMaster> They're just different styles of hackish.  Fedora could also count in that list.
[15:19] <LPhas> well, my goal is to have a working x installation possibily with a minimal window manager but also GNOME will be fine where i can run some gstreamer/python application
[15:19] <LPhas> as easily as possible
[15:19] <LPhas> so a full ubuntu installation is fine at the moment
[15:19] <GrueMaster> Then select Ubuntu Desktop or one of the other desktop environments.
[15:19] <LPhas> only that?
[15:20] <persia> Hrm.  Ubuntu offers a server product, of which many folk are fairly proud (and any number of folks run Debian as desktop)
[15:20] <GrueMaster> yes.  Just be aware that the more you select, the more of a chance it will fail due to pool churn.
[15:20] <LPhas> well... it failed
[15:21] <LPhas> persia, yep i know of ubuntu server, but it's really not my kind of server. (while i bet it has some advantages depends on what you do)
[15:21] <GrueMaster> Probably dependency issues.  I've been seeing that since Alpha 2.
[15:21] <LPhas> GrueMaster, so do you think should i try?
[15:21] <LPhas> can i install "basic ubuntu server" and then add gnome-desktop later?
[15:21] <GrueMaster> Give it a try, but don't get your hopes up.  It is installing oneiric after all.
[15:22] <LPhas> "oneiric"?
[15:22] <GrueMaster> You should be able to install ubuntu server.  YOu could also not select anything here (I recommend openssh-server as a minimum).  This will give you a minimal install and you can always add from there.
[15:23] <LPhas> let's try
[15:23] <GrueMaster> oneiric is the currently "in development" release.
[15:23] <LPhas> ok
[15:23] <GrueMaster> I'm not sure that the netinstall could be preseeded to pull from natty instead (but it would be nice).
[15:24] <LPhas> yeah, unstable is always quite.. unstable
[15:24] <LPhas> at least it was when i was using ubuntu years ago
[15:25] <GrueMaster> On arm it is more so due to the length of time it takes to rebuild dependencies.
[15:25] <LPhas> is it longer? why?
[15:26] <GrueMaster> We hope to get a cluster of pandas online soon to help with that.  Right now, we only have a small handfull of single core 512M systems doing builds.
[15:31] <LPhas> GrueMaster, can't you just use cross compilers?
[15:32] <GrueMaster> Not really.  They can be hit or miss.  And a lot of packages have post-build test suites to verify the builds.
[15:33] <LPhas> mmh i see
[15:33] <LPhas> isn't possible to use cross compilers to compile the packages and move the post-build test on the actual hardware/emulated enviroment? that would be cool
[15:34] <GrueMaster> And painful.  You would have to break up the build process, rewrite make files, bundle up partially completed builds, etc.
[15:35] <LPhas> i see that
[15:35] <GrueMaster> The reason for the poor hardware in the buildd pool is simply due to availability.  Panda is the first dual core system that was widely available.
[15:36] <GrueMaster> And economical.
[15:36] <LPhas> i see
[15:37] <LPhas> so are you actually working in canonical?
[15:37] <LPhas> (if i may ask)
[15:37] <GrueMaster> Yes.  I am the QA guy for the arm releases.  But I also do some hackery on the side, when time allows.
[15:38] <LPhas> that's really cool
[15:38] <GrueMaster> I used to do alsa development for Intel HD Audio based systems.
[15:38] <LPhas> i'we always wanted to meet a canonical guy to say "good work guys, you changed the way that linux is"
[15:39] <GrueMaster> Heh, thanks.  Glad to hear you like our work.
[15:42] <LPhas> one might like more hackish distros for himself, but only stupids can't appreciate the marvelous fact that you put a ubuntu cd (usb stick) and 30 minutes later you have a fully functioning linux based workstation with basically no effort
[15:42] <topfs2> I'll +1 that. Was annoyed at the direction natty took until I started using oneiric, regained my trust right there :)
[15:43] <GrueMaster> Part of my unofficial testing is to see if my mom can install and use it.  So far, so good.
[15:43] <topfs2> (the +1 was for the "good work .." part btw :) )
[15:43] <topfs2> haha, I Like the mom test :)
[15:43] <LPhas> still, seems that the installer didn't worked
[15:43] <LPhas> it completed successfully but it won't boot
[15:44] <topfs2> I do that constantly with xbmc also, if I can picture my mom using it its simple enough
[15:44] <LPhas> i don't have output on the serial console
[15:44] <GrueMaster> LPhas: YOu are using the netboot installer?
[15:44] <LPhas> yep
[15:44] <topfs2> for the record I installed ubuntu on my ex's moms computer a while back and she loved it so much more than windows :) soemthing I found quite a lot of fun
[15:45] <GrueMaster> Hmmm.  I'll have to check it to make sure it is setting up a serial console properly after boot.
[15:45] <LPhas> well, there's no output at all, neither from the bootloader
[15:46] <LPhas> so problem is "before the boot"
[15:46] <GrueMaster> Not even any u-boot test?
[15:47] <LPhas> not even
[15:47] <GrueMaster> *text
[15:47] <LPhas> not a single bit on the serial
[15:47] <LPhas> not a blink from the led
[15:47] <GrueMaster> Hmm.  I heard there may be a problem with the board not rebooting after install.  Try just hitting reset and see if it comes up.
[15:48] <LPhas> nope
[15:49] <LPhas> that's quite strange because apparently there are u-boot.bin MLO uImage uInitrd on the partition of the sdcard
[15:49] <LPhas> also boot.scr
[15:50] <GrueMaster> Yes, but if the kernel doesn't actually reboot the system after install, they won't come up.
[15:50] <LPhas> yeah but i rebooted the pandaboard
[15:50] <GrueMaster> Reset does nothing?
[15:51] <GrueMaster> Can you check to see if the boot flag is enabled on the SD fat partition?
[15:51] <GrueMaster> Also check the partition type.
[15:51] <LPhas> reset does nothing
[15:51] <LPhas> for the boot flag give me some minute
[15:51] <LPhas> the only sd-enabled system i have is a mac
[15:51] <LPhas> and fdisk on osx is quite different
[15:54] <LPhas> mmh, i wrote a boot flag on the partition
[15:54] <LPhas> but stil won't boot
[16:01] <GrueMaster> Hmmm.
[16:01] <LPhas> i can see two things running parted
[16:01] <LPhas> ehm fdisk
[16:02] <LPhas> /dev/sdb1   *        2048      141311       69632    b  W95 FAT32
[16:02] <GrueMaster> Unfortunately, I am still ramping up hardware wise.  I will look into this later today, after I run to the store and get some external drive enclosures.  I have drives, just no enclosures.  :(
[16:02] <LPhas> the first is that the partition doesn't start from sector 0
[16:02] <GrueMaster> That is one problem.  The other is the partition needs to be type c.
[16:02] <LPhas> "type c"?
[16:03] <GrueMaster> LBA
[16:03] <LPhas> oh
[16:03] <LPhas> well ok, i can manage to fix this i think
[16:03] <GrueMaster> Which version of the installer did you copy down?
[16:04] <LPhas> boot.img-fat-serial this i think
[16:04] <LPhas> on the guide they say that the partition should be 75 MiB
[16:04] <LPhas> should it be precisely this amount?
[16:04] <LPhas> cause i have a nice script that automatically partition the sdcard for the pandaboard
[16:04] <LPhas> but the boot partition is lik 66mib
[16:05] <GrueMaster> No, it can be as low as 20M, but 40-70 is recommended as flash-kernel backs up the old kernels.
[16:06] <persia> GrueMaster, Ncommander wrote that there was a bug which required the FAT partition to be 72MiB at https://wiki.ubuntu.com/ARM/OMAP : is this only conservative advice?
[16:06] <GrueMaster> persia: That is soley based on my recommendation from what the preinst images use.
[16:07] <persia> Heh.  And now my understanding is complete :)
[16:07] <GrueMaster> I haven't had a chance to figure out a definitive size.
[16:07] <GrueMaster> But based on kernel and initrd sizes, we could probably go down to 40M.
[16:09] <persia> That'd cover about 5 updates?
[16:09] <GrueMaster> flash kernel only stores current & 1 previous version.
[16:10] <persia> In that case, I suspect we might be able to get down to ~30, but yeah, it's complicated (and widely depends on what one has in the initramfs)
[16:11] <GrueMaster> Not sure if we care about old versions of MLO and u-boot.bin.
[16:11] <persia> Personally, I think those are even more critical.
[16:11] <persia> If you don't have a working kernel, but you have a working bootloader, you can fuss about.
[16:12] <persia> If you don't have a working bootloader, your device is bricked, unless you happen to have a device with the bootloader on removable media, or some other way to update he bootloader (e.g. via USB gadget).
[16:14] <GrueMaster> On panda's, it is easy enough to change out the bootloader, either by pulling the SD and overwriting it on a PC (or Mac), or by booting a custom kernel via usbboot.  We just don't happen to provide the custom kernel.
[16:14] <persia> ogra_, infinity: you guys fiddle with image stuff more than I: would one of you review https://code.launchpad.net/~persia/debian-installer/publish-omap-spl/+merge/67575 ?
[16:15] <persia> GrueMaster, Right.  My concern is about architecture for consumer devices.  Anything we do that presumes a development board needs to be redone later if we expect to have our software delivered retail.
[16:16] <GrueMaster> I'm less worried there, as we don't release alpha or beta software to retail channels usually.
[16:16] <GrueMaster> And for the x-loader & u-boot, they are usually tested heavily before release.
[16:19] <GrueMaster> Besides, most retail products have special partitions for each, usually just big enough to hold one copy with a little room to grow.
[16:20] <persia> And as long as we have flash-kernel not overwrite them (and don't install our versions in those images), we ought be safe.
[16:20] <persia> Of course, if our reputation grows enough that retail folk *want* our bootloaders, then the picture gets more complicated.
[16:20] <LPhas> heh the mighty script worked
[16:21] <GrueMaster> LPhas: Cool.
[16:21] <LPhas> hail to that crazy gentoist who, probably waiting hours to compile gnome, wrote it
[16:21] <GrueMaster> heh
[16:26] <LPhas> now should i try to install ubuntu-desktop?
[16:26] <LPhas> at least i could give you the precise error if it's a dependency problem
[16:26] <GrueMaster> Sure.  Try "sudo apt-get install ubuntu-desktop".
[16:27] <persia> `sudo apt-get ubuntu-desktop^` may have slightly different results (and more closely matches what would be in a default desktop install image).
[16:28] <LPhas> http://hpaste.org/48952 and tht;s your error
[16:28] <persia> Note the '^', used to distinguish a task from a package.
[16:30] <GrueMaster> LPhas: The error you are seeing is similar to what I had last friday, but with different packages.  This is good, in that it means the buildds are still churning and not failing to build a package.
[16:31] <GrueMaster> Sucks in that there is no frozen packages to pull from.
[16:34] <LPhas> GrueMaster, is there another metapackage for another desktop manager (not kde please, no kde) maybe xfce
[16:34] <GrueMaster> Not sure.  I think so.
[16:35] <GrueMaster> KDE is (was) horribly broken on arm last cycle.  While I prefer it on x86, it had serious arm specific issues.
[16:35] <LPhas> KDE is horribly broken everywhere :p
[16:35] <GrueMaster> But I think the kde dev's have been working on those.
[16:37] <GrueMaster> Depends on point of view.  A lot of people were upset with 4.0 and how nothing worked.  They don't fully realize that 4.0 was a development release to enable devs to port their 3.5 apps over.
[16:37] <LPhas> yeah, just kidding
[16:37] <LPhas> well, after installing xinit, startx works
[16:37] <LPhas> that's a start
[16:37] <GrueMaster> Cool.
[16:38] <GrueMaster> Should be able to get lxde or xfde to install.
[16:38] <LPhas> lwm would be enough
[16:38] <LPhas> now i've to get the closed source video driver work
[16:39] <LPhas> and get a decent resolution
[16:39] <GrueMaster> What resolution do you have now?
[16:39] <persia> LPhas, If you like LXDE, try installing lubuntu-desktop: it's a prepared environment based on LXDE for Ubuntu.
[16:40] <GrueMaster> That should be up to the frame buffer.
[16:49] <LPhas> switching to pvr-omap4 have i just to install it and hal handles all the stuff or is there some configuration to alter in xorg?
[16:50] <persia> LPhas, It ought be all autodetected.
[16:50] <LPhas> that's cool
[16:52] <mahmoh> persia: init is running 100% and I cannot figure out why, who can I ping to take a look at it?
[16:57] <persia> You could file a bug.
[16:57] <Daviey> mahmoh: have you tried killing it? :)
[16:57] <persia> You could try attaching strace to upstart to see if it tells you anything useful.
[16:57] <persia> Daviey, That just reboots.
[16:57] <mahmoh> HUP
[16:57] <Daviey> persia: incorrect... try killing init.
[16:57] <mahmoh> yeah, that's the plan but I'm outsourcing it ;)
[16:58] <mahmoh> Daviey: yeah, but I want to know why first ;)
[16:58] <persia> Daviey, The behaviour changed?  It meant "reboot" for a long time.
[16:59] <LPhas> mmh not sure but it seems to have worked
[16:59] <persia> Oh, interesting.  It doesn't appear to do anything I can detect (nor log anything anywhere I tend to look)
[16:59] <LPhas> still the resolution is still VGA
[16:59] <LPhas> well, time to go
[16:59] <Daviey> persia: i suspect it's one of the upstart changes.
[16:59] <mahmoh> I could just ask it to dump a trace, hmmm
[16:59] <LPhas> thank you guy, you were wonderful, i owe you a beer
[16:59] <LPhas> see you
[17:00] <persia> Daviey, I suspect so, as something called "sysvinit" ought behave like a proper System V init :)
[17:00] <Daviey> lol
[17:01] <ogra_> who uses that anyway
[17:01] <persia> ogra_, I did, for > 20 years.
[17:03] <ogra_> stop living in the past then :)
[17:04] <persia> Yeah, well.  I'm learning.
[17:05] <ogra_> persia, your merge looks fine apart from the broken changelog
[17:05] <persia> So, when it takes over an hour for bzr to push 3019 bytes to LP, other folk sometimes push their own branches.
[17:05] <ogra_> yeah
[17:06] <persia> I'm not willing to wait another hour to fix that: I can send a patch somewhere *OR* someone else can fix the changelog.
[19:50] <mahmoh> persia: ping, here's one for you, tried getting a kernel crash but no output to the serial for panda - any ideas why or why not?
[19:51] <persia> You had working serial console right before the crash?
[19:51] <persia> (also, best to ask questions generally: even if you think I am likely to answer, someone else may answer sooner, and they might also be more well informed)
[19:53] <mahmoh> yes, ttyO2
[19:53] <mahmoh> boot info. goes to the console just fine
[19:54] <infinity> Are you sure you're experiencing a kernel crash?
[19:55] <infinity> Hardware lockups != Kernel crashes.  And the former will, for pretty obvious reasons, give you no output.
[19:55] <mahmoh> manually caused it to get the stack (or tried to at least), yes
[19:55] <fredim> hello, I need to get ubuntu 10.04 preinstalled for beagle
[19:55] <infinity> Oh.
[19:57] <persia> fredim, Such an image was not produced (or if it was, it was a short-lived tech demo image).
[19:57] <persia> fredim, Could you use 10.10 or 11.04?  Alternately, would you be able to do an install from a bare rootfs?
[19:58] <persia> mahmoh, Hrm.  Dunno.  Check the kernel config: maybe it isn't set to dump to console when it crashes.
[19:58] <fredim> persia, xibo client (http://wiki.xibo.org.uk/wiki/Install_Guide_NET_Client) not suported ubuntu >= 10.10
[19:59] <mahmoh> persia: thx
[20:00] <persia> fredim, So, I think you're not going to end up with a nice solution.  My memory is that there were still isses with the .NET stack for armel in lucid, plus there don't seem to be images for OMAP3 for lucid.
[20:00] <mahmoh> CONFIG_CMDLINE="console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootwait mem=1G"
[20:01] <persia> So, you get a choice between creating your own mess, and hoping it works, potentially with support from xibo, *or* using a newer release which is known to work (11.04 finally had decent .NET support for armel), but that isn't supposed by xibo.
[20:02] <persia> mahmoh, Not that config: /proc/config (and no, I don't know which options govern where to dump kcrashdumps)
[20:04] <mahmoh> it's the same (?)
[20:04] <persia> Err.  Sorry.  /boot/config
[20:04] <persia> Well, that should match /proc/config
[20:04] <mahmoh> right, they happen to be identical (haven't upgraded since install)
[20:04] <persia> Your entry matches /proc/cmdline
[20:05] <mahmoh> all the same
[20:05] <infinity> persia: http://cdimage.ubuntu.com/ports/releases/10.04/release/ seems to disagree with you about there having been "no images" (though none were what you'd call "preinstalled", I imagine) for lucid/omap, but your argument about mono not actually working back then probably stands anyway. :P
[20:05] <mahmoh> ttyO2
[20:05] <persia> Sure.  I'm just saying that I have never heard of someone seeing a kernel crash dump on serial with an Ubuntu kernel, so I'm unsure if the kernel is configured to deliver those.
[20:06] <persia> infinity, Ah, thanks for finding that.  I forgot that we didn't drop the "ports" designation for cdimage until maverick.
[20:06] <mahmoh> I've seen plenty, but I think it was turned on ... let me go ask
[20:06] <persia> fredim, ^^ has desktop and server images for omap.  No idea if the .NET support is good enough for xibo.
[20:07] <persia> mahmoh, IF you *usually* get crashdumps, but just not in this case, then I'm inclined to agree with infinity that it's probably a fault rather than a crash
[20:10] <fredim> Thanks, persia!   I'll see what I can do
[20:10] <persia> fredim, Sorry for my confusion.  Thank infinity.
[20:19] <mahmoh> I think it has to be turned on so we're ok
[20:20] <persia> Ah, good.  That behaviour is sane.
[20:20] <persia> How does one turn it on and off?
[20:21] <mahmoh> "dmesg -n 8"  increasing logging which in turn dumps to console, resetting to 4 turns it back off again
[20:29] <mahmoh> rsalveti: I'm trying the latest (your dev release from yesterday - "U-Boot 2011.06-dirty (Jul 11 2011 - 01:31:39)" on my old board and when I try usb start I get "scanning bus for devices... The request port(2) is not configured" then the board resets and I get X-Loader again (1.5.0 Jun 28 2011) - any ideas?
[20:29] <mahmoh> do I have to update the X-Loader?
[21:45] <rsalveti> mahmoh: which x-loader are you using?
[21:46] <rsalveti> mahmoh: was it working before with the same board?
[21:46] <rsalveti> mahmoh: if you grab current x-loader and u-boot-linaro binaries from the packages, it should work same way as before
[22:13] <mahmoh> rsalveti: I'll update it and try it tomorrow (I'm not near the board right now) but the x-loader must change too?  if so, then that's probably what did it
[22:14] <rsalveti> mahmoh: not if you got it working before
[22:14] <mahmoh> rsalveti: that part I don't know, I'll find out tmw though ;)
[22:27] <rsalveti> GrueMaster: mahmoh: bug 809015
[22:27] <ubot2> Launchpad bug 809015 in u-boot-linaro "u-boot lacks unique mac address on Pandaboard while netbooting" [Low,Confirmed] https://launchpad.net/bugs/809015
[22:28] <persia> rsalveti, Thanks for getting that logged and assigned.  Does this mean anything in terms of delivery timing expectations?
[22:31] <rsalveti> persia: linaro 11.07, end of this month
[22:32] <persia> Wonderful!  Thank you very much.
[22:33] <persia> Is this the super solution for all vendors, or just taking the code from the omap kernel and putting it in u-boot as a stop-gap?
[22:36] <rsalveti> persia: for now we want the same solution for omap 4 as we have at the kernel
[22:36] <rsalveti> persia: to be a stop-gap and having a fully functional u-boot with tftp + pxe
[22:36] <rsalveti> that can be used by the release
[22:36] <persia> Heh, yeah, that makes sense.
[22:36] <rsalveti> but we should also start the discussion for the generic vendor solution, sure
[22:39] <persia> What's the best way to start that discussion?  I liked wookey's proposal, but it probably ought be formalised somehow.
[22:40] <rsalveti> linaro boot architecture + u-boot m-l I'd say
[22:41] <persia> wookey, Would you be up for summarising your proposal there?  Would you prefer that I try to paraphrase it to start the discussion?
[22:45] <wookey> which proposal are we talking about?
[22:46] <wookey> I'm having a big fght with mercurial on a server right now
[22:50] <persia> wookey, The proposal about what bitfields made sense for pregenerated MAC addresses for deficient hardware.
[22:53] <wookey> ah. I see
[22:54] <wookey> persia: feel free to paraphrase - It was just an idea (from some dim memory of doing this on LART circa 2003)
[22:54] <wookey> and DVCS officially does my head in OK?
[22:55] <persia> wookey, Heh, OK.  I seem to remember something like 4 bytes for vendor, 2 bytes for board, and the rest based on a detectable identifier on the system.  Does that sound like a roughly accurate paraphrase?
[22:55] <persia> DVCS is best experienced when *someone else* is the server admin :)
[22:55] <wookey> I was thinking PCI ID for vendor - that's only 2 bytes IIRC
[22:56] <wookey> or ethernet ID if you prefer
[22:56]  * persia reads the media access control address specification
[22:56] <wookey> and one byte for board ID ought to be enough
[22:58] <wookey> the whole thing is only 48 bits - 6bytes IIRC
[22:58] <persia> Right.  Three bytes for "Organisationally Unique Identifier", some of which are reserved for special purposes, and 3 bytes for the NIC.
[23:00] <persia> Looking at the spec, I think it's 1 bit for "unicast", 1 bit for "This is a locally administered address", 6 bits for board ID, and 16 bits for vendor ID.  Then 24 bits for the specific device.
[23:01] <persia> Does that seem wide enough?  Do we expect more than 127 deficient boards from the same vendor in medium time?
[23:01] <persia> Err, 64
[23:14] <persia> Oh, nifty.  The IEEE Registration Authority only delivers 12 bits for vendor ID, including the reserved bits, so 10 bits in practice.
[23:59] <mahmoh> rsalveti: thx! ( persia too )