[00:05] <persia> rcn-ee, Looking at your example, is that an entire menuing system for the flash on the beagles?
[00:06] <rcn-ee> the idea behind that was to stop people from accidently flashing nand the xM's..
[00:06] <rcn-ee> there's no nand of course, but i got a couple bug reports with interesting errors... ;)
[00:06] <persia> Heh.
[00:07] <persia> I was wondering: would it be worth replacing the skeleton system we ship in Ubuntu with something like that (slightly more robust)?
[00:09] <rcn-ee> i've actually been working on something even crazier... autogenerate it at boot: https://github.com/RobertCNelson/netinstall/blob/master/mk_mmc.sh#L127 then with sed: https://github.com/RobertCNelson/netinstall/blob/master/mk_mmc.sh#L184 (so far the same script boots on imx53,beagle,panda,igevp2.. so not as many as you guys yet..)
[00:10] <rcn-ee> /boot/image flash time..
[00:15] <persia> Wow!  So this would be some generic framework that on first boot would (ideally) generate the perfect boot.scr for the target platform, and place that in the right place for the next boot?
[00:16] <persia> So, there's two points of wonder I have remaining:
[00:17] <persia> 1) If we put several kernels in some directory available to u-boot, would this be able to select the right one?
[00:17] <persia> 2) Would this allow us to construct a u-boot that was capable of booting on all those devices, or would there still need to be a separate compilation of u-boot for each image?
[00:18] <rcn-ee> i was actually hacking up rootstock to do the same thing.. install both the omap and imx image's then select the right one by which board was selected..
[00:18] <rcn-ee> then one image for many boards.. (till device tree is ready)
[00:18] <persia> Could I convince you to do that hacking with debian-cd directly?
[00:19] <persia> That makes it trivial for us to use it to generate such generic images (as opposed to rootstock, where we'd have to port the code and we have to recommend nobody uses for production purposes)
[00:19] <rcn-ee> is that the same one ogra,lool..  keeps reminding me to use? ;) do you have the tree? i just finished adding debian armhf support to rootstock this last weekend.. ;)
[00:20] <persia> lp:~ubuntu-cdimage/debian-cd/ubuntu
[00:20] <persia> It is most likely precisely the same codebase everyone else keeps suggesting :)
[00:20] <persia> It's the one we use to build the images we ship.
[00:25] <lool> gosh
[00:25] <persia> ... ?
[00:26] <lool> My eyes are wide open at the shell pieces that rcn linked to, and also by the recommendation to hack it in debian-cd directly  :-)
[00:26] <lool> in fact I'd recomment the opposite  ;-)
[00:27] <persia> How do you mean?
[00:27] <lool> Have a simple interface to generate useful images in a script which consumes e.g. the name of the vmlinuz file to install and any other useful inputs and then use that from debian-cd
[00:27] <persia> I thought that the linked code was boot.scr code, rather than shell code.
[00:27] <lool> and other places
[00:27] <persia> And that one would just drop it in verbatim in debian-cd
[00:27] <persia> Ah, right.  I should look at the top of the files.
[00:28] <persia> Yeah, having a utility that did the right thing, and having debian-cd call that utility is lots cleaner, if it's image-build-time, rather than first-boot-time that we calculate the boot script.
[00:29] <lool> I considered proposing linaro-image-tools to do this
[00:29] <persia> That said, I'd *much* rather see a first-boot-time solution.
[00:29] <lool> it has the advantage of being python and with decent test coverage, supporting a bunch of boards
[00:29] <lool> but I'm not entirely sure it's the right approach
[00:30] <lool> I think I should stop here, it's not reasonnable to start such a discussion in my local time
[00:30] <persia> Heh.  Sleep well.
[00:30] <persia> I agree it would be nice to have a tool that did the right thing that we could use on the image builders *and* end user environments.
[00:31] <persia> I also feel fairly strongly that we should strive for a sufficiently generic model that we *don't* need to have N different images, all with the same rootfs.
[00:31] <persia> (or nearly the same: ignore things like /lib/modules for now)
[00:31] <lool> Yes, so there's actually a forum where we discuss exactly this
[00:31] <rcn-ee> exactly, one generic image is all we need, at some point the user will have to flash something, at that point is where the customization should be done.
[00:32] <lool> but to support current SoCs, we will need some middle layer adapting the boot of each SoC to some standard image format for a while, so the question remians
[00:32] <persia> rcn-ee, Users make mistakes.  I want it to just work, without customisation.
[00:32] <lool> rcn-ee: Right now, there are different expectations between SoCs which don't allow this, but we could progressively transition in such a world
[00:33] <persia> lool, Indeed.  It's messy now, until we have more mature bootloaders, and potentially a new generation of SoCs with ROM that integrates nicely with the richer bootloaders.
[00:33] <lool> however, we could have some generic image format right now, and provide mini-images for SoCs we care about which allow loading this image format
[00:34] <rcn-ee> lool, i was actually working on something silly. (till device tree's done..) have both and imx/omap image installed in the rootfs, then having the bootloader pick the correct one, based on what board the user selected... so you'd have one base iamge for imx and omap.. per say..
[00:34] <lool> rcn-ee: so with Linaro "images" we split the soc specific bits out, and you combine them when writing the SD image
[00:34] <persia> This is the function of linaro-image-tools
[00:35] <lool> e.g. you download an Ubuntu rootfs, then imx specific bits then omap specific bits and you run linaro-image-tools to create omap or imx SD card images
[00:35] <rcn-ee> yeah, pretty much...
[00:36] <lool> while imx + OMAP might be combined in a single image, it's becoming exponentially complex when you factor more SoCs or things like aligning partitions, different partition types, and other constraints
[00:36] <persia> I like better the idea of merged images, letting the user select the right thing, but last I heard, one needed a different build of u-boot for each board (and sometimes each revision of a board), which makes this considerably harder to accomplish.
[00:36] <lool> like Samsung expects its bootloader near the imx one, so you wouldn't be able to do imx + samsung support
[00:38] <rcn-ee> yeah, i haven't expanded enough outside imx/omap yet to see the bigger picture yet.... ;)
[00:38] <lool> we didn't discuss detecting which SoC you're on; John Rigby had some idea that this could be done; it's also a fun research project, but it's pretty tricky
[00:38] <lool> and that's not needed in the case of interim middle layer images
[00:39] <persia> And it's very bootloader-specific.  I'm not sure devicetree helps at all, because we still have to find a way to get to linux.
[00:39] <lool> just detecting variations of OMAP3 boards to infer their type of DDR is already quite hard to do reliably
[00:39] <NekoXP> yeah the real issue here is you guys are *recompiling and reflashing u-boot* which is totally bad mojo and brick city awaits
[00:39] <lool> it's not really a problem of which bootloader
[00:39] <lool> the hardware doesn't provide the information to start with
[00:40] <lool> NekoXP: I don't think this relates at all
[00:40] <lool> but I can certainly say that we can't work on any such project if we aren't rebuilding u-boot ourselves
[00:40] <persia> NekoXP, We only do that for dev boards.  We don't reflash u-boot for retail devices (or reflash u-boot past first install anyway)
[00:40] <lool> at least not on this target SoC, someone else will have to do it
[00:42]  * lool 'night! &
[00:42] <persia> lool, Sleep well
[02:13] <rsalveti> at least for omap it should be ok to have just one u-boot at least
[02:14] <rsalveti> but still, we need something to provide the device id
[02:14] <rsalveti> and that would be SPL or x-loader
[02:14] <rsalveti> problem is that there's no pattern at all
[02:49] <chedder> I have a question about network (Wired & Wireless), today I loaded this image on my board "http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/10.10/release/ubuntu-netbook-10.10-preinstalled-netbook-armel+omap4.img.gz". when it installed, I was at a desktop and cound not enable the wireless or wired network - does anyone know what I am missing? I am a newbe btw
[03:20] <persia> chedder, What does network manager tell you about available networks?
[06:14] <siji> hi all
[06:50] <siji> i have build ubuntu natty by using rootstock
[06:50] <siji> On beagleboard
[06:50] <siji> but my ethernet is not working
[06:50] <siji> any solution ?
[06:53] <persia> What sort of ethernet do you have?
[06:53] <persia> If it's like the one on my Zippy, I think the issue is a lack of kernel drivers for it.
[06:53] <persia> Or improper hotplug support.
[06:55] <siji> persia, it's the defualt ethernet cming with beagleboard
[06:55] <siji> as u said i doubt it's kernel driver issue
[06:55] <siji> I have build natty from rootstock
[06:55] <persia> I think you have a different beagleboard than I: mine only has ethernet on a breakout board (zippy), and that ethernet has never worked for me.
[06:56] <siji> oh ok
[06:56] <persia> I've always suspected a driver issue, because USB ethernet works fine.
[06:56] <siji> oh ok
[06:56] <siji> this was working fine with angstrom
[06:56] <persia> By the way, you know that rootstock is good for experimentation, but not entirely suitable for the creation of production images, right?
[06:57] <siji> I feel the same
[06:57] <siji> One more clarification I needed
[06:57] <persia> Heh.  I suspect angstrom has some patches to the kernel, or patches to udev to handle that (I'm not sure which is needed).
[06:57] <siji> ok
[06:58] <siji> Actullay in the boot directory of the natty vmlinux and initrd.img etc.. is 2.6.39
[06:58] <siji> But my uImage is for 2,6,38
[06:58] <siji> whether this will be the problem ?
[06:59] <persia> Maybe, but only maybe.  More important than the contents of /boot are whether you have anything in /lib/modules/ that matches the currently running kernel
[07:00] <siji> let me check
[07:00] <siji> oh right
[07:01] <siji> all the modules are only for 2.6.39
[07:01] <siji> So either have to put 2.6.38 module there or ,hve to build new uImage for 2.6.39
[07:01] <siji> Right ?
[07:02] <persia> If you want to be able to load drivers, yeah :)
[07:03] <siji> ok
[07:03] <siji> let me give a try
[07:11] <siji> persia, i guess it's detected now
[07:11] <siji> lights are cming from etehrnet card
[07:11] <siji> Trying to configure it ..
[07:11] <persia> Cool!
[07:19] <siji> persia, yes it's start working
[07:19] <siji> Even my Wifi Module also detected
[07:20] <siji> ;)
[08:01]  * persia suspects mmcqd isn't supposed to consume more cycles than any other process
[08:02] <infinity>  1131 ?        D     51:39 [mmcqd]
[08:02] <infinity> That's 10 days uptime on a system that's a full archive mirror.
[08:02] <infinity> It's not the top offender, but it's close.
[08:03] <persia> You're clearly abusing your SD cards almost as much as I then
[08:03] <infinity> (If the mirror wasn't on external storage, it probably would be top)
[08:03] <infinity> Well, my root's on SD, cause I'm lazy.
[08:03] <persia> This is on a system with root on /dev/sda
[08:04] <infinity> Oh.  Well, stop doing mean things to your CD cards.
[08:04] <infinity> (writing test images over and over?)
[08:04] <persia> Worse: pieces of test images.
[08:05] <infinity> Ick.
[08:05]  * persia hopes to get to actual test images later.
[08:05] <infinity> I was supposed to be asleep, wasn't I?
[08:05] <infinity> I got distracted by Vi Hart talking about pie.
[08:06] <infinity> Or pi.
[08:06] <infinity> Or both.
[08:06] <persia> My views on timezones and sleeping habits being what they are, I'm not sure I'm qualified to answer that question.
[08:06] <infinity> I lost trach.
[08:06] <persia> Tau!
[08:06] <infinity> track, too.
[10:56] <rsalveti> ppisati: ogra_: who is integrating the TI LT kernel at ubuntu?
[10:57] <persia> rsalveti: Last I knew it was ppsati
[10:57] <persia> But it was never clear to me if that was a LT kernel or a BSP kernel
[10:58] <rsalveti> that's also what I want to know :-)
[10:59] <rsalveti> what tree ubuntu is planning to use for omap 4, who is doing the work and how related it is with the TI LT tree
[11:10] <ppisati> rsalveti: bsp kernel, based on agreen's kernel-tilt/master
[11:10] <ppisati> and here is if you want to try it out
[11:10] <ppisati> http://people.canonical.com/~ppisati/ti-omap4-next/linux-image-3.0.0-1-omap4_3.0.0-1.0~9765dd1_armel.deb
[11:11] <ppisati> git://kernel.ubuntu.com/ppisati/ubuntu-oneiric.git ti-omap4-next
[11:11] <ppisati> if you want to tweak it
[11:13] <rsalveti> ppisati: so, it's TI LT + ubuntu sauce?
[11:13] <ppisati> yep
[11:14] <ppisati> oneiric/master + kernel-tilt/master + $omap4_only_stuff
[11:14] <rsalveti> hm, ok, we also want the same thing for linaro, so I'm thinking how should we avoid duplicate work
[11:14] <ppisati> where omap4_only_stuff so far is only some config
[11:14] <rsalveti> ok, that's fine
[11:14] <ppisati> pick it entirely
[11:15] <rsalveti> and in theory there's no reason to keep patches !config in $omap4_only_stuff
[11:15] <rsalveti> as agreen is taking most of the patches
[11:15] <ppisati> agree
[11:16] <rsalveti> jcrigby: so even less work for us atm
[11:17] <rsalveti> ppisati: and when are you planning to push this to omap4 branch?
[11:18] <ppisati> rsalveti: well, there's one issue with audio still, but i think we can skip it ATM
[11:18] <ppisati> if it gets some testing, i can push it next week
[11:19] <ppisati> btw, IIRC exactly next week the SRU team open the window for new kernel cycle
[11:19] <ppisati> so it's a perfect timing
[11:21] <rsalveti> ppisati: cool, good to know
[11:22] <ppisati> whos is using omap4/panda?
[11:23] <ppisati> me, you, grue, ogra and janimo?
[11:23] <janimo> ppisati, I do
[11:23] <janimo> stock oneiric
[11:23] <janimo> upgraded from natty
[11:23] <ppisati> janimo: cool, so can you give it a try?
[11:23] <ppisati> janimo: http://people.canonical.com/~ppisati/ti-omap4-next/linux-image-3.0.0-1-omap4_3.0.0-1.0~9765dd1_armel.deb
[11:24] <janimo> ppisati, sure
[11:25] <ppisati> in the meantime...
[11:25]  * ppisati -> lunch
[11:25]  * janimo grumbles about canonicaladmin javascript bugs
[12:41] <siji> persia, can u pls tell me abt where can I get pvr drivers for the kernel 2.6.38
[12:42] <siji> is it bundled with omap ti Sdk ?
[12:47] <persia> siji, You want https://wiki.ubuntu.com/ARM/OMAP/Graphics
[12:48] <persia> I don't know whether it is in the TI SDK, or how TI licenses it to their customers: for playing around, feel free to use our code.
[12:48] <siji> persia, ok
[12:49] <persia> For production shipment, it's worth double-checking the terms of your supplier arrangement with TI
[12:49] <siji> sure will do
[12:49] <siji> persia, i have tried this link
[12:50] <siji> it generated the driver only for 2.6.35
[12:50] <siji> not for 2.6.38
[12:52] <persia> You installed libegl1-sgx-omap3 libgles1-sgx-omap3 and libgles2-sgx-omap3, and it didn't autocompile for your installed kernel?
[12:53] <siji> no
[12:53] <persia> Well, what did you do then?
[12:54] <siji> it has created one more module folder at /lib/modules/2.6.35 and pvr folder created there
[12:54] <siji> 2.6.35-n90  I guess
[12:55] <siji> which is i think not compatible  with .38
[12:55] <siji> anyway let me give a try again
[13:21] <siji> persia, Setting up linux-image-2.6.35-1-n900 (2.6.35-1.3.1) ...
[13:21] <siji> Running depmod.
[13:21] <siji> update-initramfs: Generating /boot/initrd.img-2.6.35-1-n900
[13:23] <persia> siji: Hrm?  Aren't you working on a Beagle derivative?  Why use the n900 kernel?
[13:24] <siji> am not using actually
[13:24] <siji> it by default installed
[13:24] <persia> Which image did you start from?
[13:24] <siji> 2.6.38
[13:24] <persia> As long as you start from one of the omap images, the n900 kernel shouldn't be installed.
[13:24] <persia> That's only default for the n900 images.
[13:24] <chedder> looking for help finding the modules to enable networking
[13:25] <chedder> i am a newb - very cluness
[13:25] <siji> persia, not getting you
[13:25] <chedder> i am running a pandaboard
[13:25] <chedder> I am using the 10.10 image, any thoughts
[13:27] <persia> chedder: does your uname -a match the contents of /lib/modules?
[13:27] <persia> siji: So, there's lots of kernels in the Ubuntu archive.  You want one ending with -omap.  The -n900 kernel might work on your hardware, but it might not.
[13:27] <siji> persia, ko
[13:27] <siji> *ok
[13:27] <persia> siji: So, if you started with one of the armel+omap images, you won't have linux-n900 installed by default, and you won't be building stuff for .35 kernels.
[13:28] <siji> persia, got your point
[13:30] <siji> let me recheck my rootstock parameters
[13:30] <persia> If you're just saying "gimme a kernel that works on this hardware", you might end up with n900, as that is also an omap SoC: you might have to specify the kernel you want.
[13:31] <chedder> ummm no idea :)
[13:31] <siji> ok
[13:31] <siji> chedder, which kernel u are using ?
[13:31] <siji> uname -a  will tell you that
[13:31] <chedder> I used this "http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/10.10/release/ubuntu-netbook-10.10-preinstalled-netbook-armel+omap4.img.gz"
[13:31] <persia> chedder: OK.  So, at the prompt, run `uname -a`.  Also run `ls /lib/modules`.  Check to make sure that you have modules (in /lib/modules) for the kernel you're running (the version is shown in uname)
[13:32] <ogra_> lool, around ?
[13:32] <persia> If you just booted that image, and waited for the resize, and went through the OEM wizard, networking should just work.
[13:32] <chedder> both wired and wireless?
[13:33] <persia> For wireless, you might need to enable the TI PPA.  I forget (I only use wired on mine).
[13:34] <chedder> a working wired connection would be just fine
[13:34] <persia> OK.  So there's two ways to make wired work.
[13:35] <persia> 1) When you're done booting, use the network manager applet to select a wired network.
[13:35] <persia> 2) read interfaces(5), and edit /etc/interfaces
[13:35] <persia> Of these, 1) is *lots* easier.
[13:38] <siji> persia, can pls have a look into my rootstock parameters @http://paste.debian.net/122989/
[13:38] <persia> I'm not familiar with rootstock.  I used it once, a *long* time ago, and never liked it.
[13:38] <siji> oh ok
[13:38] <persia> I'll look, but I don't promise much.
[13:39] <siji> no issues
[13:39] <lool> ogra_: half
[13:40] <ogra_> lool, i'm playinf with your flash-kernel patch for triggers and noticed that you run from /etc/initramfs/post-update.d/ ...
[13:40] <persia> siji: I'll recommend you use an Ubuntu kernel: try adding "linux-omap" to the seed list, and dropping the kernel0image line.
[13:40] <siji> ok
[13:40] <persia> Mind you, this may not actually work: I'm not sure what "kernel-image" does.
[13:41] <ogra_> lool, the content of that dir is only executed by update-initramfs -u ... not -c, so it doesnt solve the problem of running at kernel upgrades
[13:41] <siji> persia, will give a try
[13:41] <ogra_> lool, or do i misunderstand the code completely ?
[13:43] <siji> (building the image with "linux-omap" )
[13:49] <lool> ogra_: I don't remember that part anymore, it's possible that I didn't handle all cases
[13:50] <persia> rsalveti, I just noticed the last line at https://wiki.ubuntu.com/ARM/OMAP/Graphics : did you ever pursue that backport?
[13:50] <ogra_> well, it does implement triggers just fine, it just doesnt change anything in the faulty behavior
[14:02] <lool> ogra_: I think I had described this part of the problem in a separate message
[14:02] <ogra_> hm, k
[14:05] <lool> ogra_:  /etc/initramfs/post-update.d and /etc/kernel/postinst.d calls keep a
[14:05] <lool>  note of which kernel initrd are being touched, and update
[14:05] <lool>  /var/lib/flash-kernel/known-kernels with the data.  flash-kernel would
[14:05] <lool> ogra_: maybe I failed sending the etc/kernel snippet though
[14:06] <ogra_> yeah
[14:06] <ogra_> i dont see it
[14:06] <ogra_> well, i think for now i'll go with a simple implementation in our flash-kernel
[14:17] <rsalveti> persia: afaik, yes
[14:23] <persia> Odd.  I don't see it in the archive.
[14:23] <persia> Is it blocked on testers?
[15:09] <siji> persia, till now everything is happening smoothly
[15:10] <siji> I have made the image from rootstock , with 2.6.38
[15:10] <siji> Just installing sgx packages
[15:10] <siji> now it's only installing 2.6.38 header
[15:14] <persia> siji, Heh, excellent.
[15:14] <persia> Random stuff on the net might work (and rcn-ee's stuff tends to be fairly good), but it's often safest to stick to the packages in the repositories until you have something *nearly* working, and then get patches in (best if you can get patches that can be applied to Ubuntu).
[15:27] <siji> ok
[15:33] <siji> persia, yes it's starts working
[15:33] <siji> :)
[17:56] <ogra_> GrueMaster, some testing of my recent flash-kernel change for bug 701698 would be nice next week :)
[17:56] <ubot2> Launchpad bug 701698 in boot "update-initramfs -c does not update the bootloader" [High,Triaged] https://launchpad.net/bugs/701698
[17:56] <GrueMaster> Oh, you actually fixed it?
[17:56] <ogra_> well
[17:57] <ogra_> i worked around it, lool has a real fix but thats very complex
[17:57] <ogra_> with my fix it can happen that flash-kernel is run multiple times
[17:58] <ogra_> during one apt-get (dist-)upgrade  run if you have more than one kernel package you get
[17:58] <GrueMaster> Ok, I'll make it a point to test next week.  Is this an SRU or oneiric only fix?
[17:58] <ogra_> oneiric only until after my vacation :)
[17:58] <GrueMaster> ok
[17:58] <ogra_> its adding one file so SRU should be easy
[21:01] <rsalveti> mahmoh: GrueMaster: u-boot is correctly setting the mac address now
[21:01] <rsalveti> and it's the same one detected by the kernel
[21:01] <rsalveti> just booted here with pxe and it all went fine
[21:01] <rsalveti> :-)
[21:03] <infinity> rsalveti: \o/
[21:12] <mahmoh> rsalveti: 2/2, thx!
[22:49] <GrueMaster> rsalveti: i'll test it once the IO tests finish, probably tomorrow.