persiarcn-ee, Looking at your example, is that an entire menuing system for the flash on the beagles?00:05
rcn-eethe idea behind that was to stop people from accidently flashing nand the xM's..00:06
rcn-eethere's no nand of course, but i got a couple bug reports with interesting errors... ;)00:06
persiaI was wondering: would it be worth replacing the skeleton system we ship in Ubuntu with something like that (slightly more robust)?00:07
rcn-eei'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:09
rcn-ee/boot/image flash time..00:10
persiaWow!  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:15
persiaSo, there's two points of wonder I have remaining:00:16
persia1) If we put several kernels in some directory available to u-boot, would this be able to select the right one?00:17
persia2) 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:17
rcn-eei 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-eethen one image for many boards.. (till device tree is ready)00:18
persiaCould I convince you to do that hacking with debian-cd directly?00:18
persiaThat 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-eeis 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:19
persiaIt is most likely precisely the same codebase everyone else keeps suggesting :)00:20
persiaIt's the one we use to build the images we ship.00:20
persia... ?00:25
loolMy 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
loolin fact I'd recomment the opposite  ;-)00:26
persiaHow do you mean?00:27
loolHave 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-cd00:27
persiaI thought that the linked code was boot.scr code, rather than shell code.00:27
looland other places00:27
persiaAnd that one would just drop it in verbatim in debian-cd00:27
persiaAh, right.  I should look at the top of the files.00:27
persiaYeah, 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:28
loolI considered proposing linaro-image-tools to do this00:29
persiaThat said, I'd *much* rather see a first-boot-time solution.00:29
loolit has the advantage of being python and with decent test coverage, supporting a bunch of boards00:29
loolbut I'm not entirely sure it's the right approach00:29
loolI think I should stop here, it's not reasonnable to start such a discussion in my local time00:30
persiaHeh.  Sleep well.00:30
persiaI 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:30
persiaI 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
loolYes, so there's actually a forum where we discuss exactly this00:31
rcn-eeexactly, 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:31
loolbut 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 remians00:32
persiarcn-ee, Users make mistakes.  I want it to just work, without customisation.00:32
loolrcn-ee: Right now, there are different expectations between SoCs which don't allow this, but we could progressively transition in such a world00:32
persialool, 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
loolhowever, we could have some generic image format right now, and provide mini-images for SoCs we care about which allow loading this image format00:33
rcn-eelool, 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
loolrcn-ee: so with Linaro "images" we split the soc specific bits out, and you combine them when writing the SD image00:34
persiaThis is the function of linaro-image-tools00:34
loole.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 images00:35
rcn-eeyeah, pretty much...00:35
loolwhile 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 constraints00:36
persiaI 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
loollike Samsung expects its bootloader near the imx one, so you wouldn't be able to do imx + samsung support00:36
rcn-eeyeah, i haven't expanded enough outside imx/omap yet to see the bigger picture yet.... ;)00:38
loolwe 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 tricky00:38
looland that's not needed in the case of interim middle layer images00:38
persiaAnd 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
looljust detecting variations of OMAP3 boards to infer their type of DDR is already quite hard to do reliably00:39
NekoXPyeah the real issue here is you guys are *recompiling and reflashing u-boot* which is totally bad mojo and brick city awaits00:39
loolit's not really a problem of which bootloader00:39
loolthe hardware doesn't provide the information to start with00:39
loolNekoXP: I don't think this relates at all00:40
loolbut I can certainly say that we can't work on any such project if we aren't rebuilding u-boot ourselves00:40
persiaNekoXP, 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
loolat least not on this target SoC, someone else will have to do it00:40
* lool 'night! &00:42
persialool, Sleep well00:42
rsalvetiat least for omap it should be ok to have just one u-boot at least02:13
rsalvetibut still, we need something to provide the device id02:14
rsalvetiand that would be SPL or x-loader02:14
rsalvetiproblem is that there's no pattern at all02:14
chedderI 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 btw02:49
persiachedder, What does network manager tell you about available networks?03:20
sijihi all06:14
sijii have build ubuntu natty by using rootstock06:50
sijiOn beagleboard06:50
sijibut my ethernet is not working06:50
sijiany solution ?06:50
persiaWhat sort of ethernet do you have?06:53
persiaIf it's like the one on my Zippy, I think the issue is a lack of kernel drivers for it.06:53
persiaOr improper hotplug support.06:53
sijipersia, it's the defualt ethernet cming with beagleboard06:55
sijias u said i doubt it's kernel driver issue06:55
sijiI have build natty from rootstock06:55
persiaI 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:55
sijioh ok06:56
persiaI've always suspected a driver issue, because USB ethernet works fine.06:56
sijioh ok06:56
sijithis was working fine with angstrom06:56
persiaBy the way, you know that rootstock is good for experimentation, but not entirely suitable for the creation of production images, right?06:56
sijiI feel the same06:57
sijiOne more clarification I needed06:57
persiaHeh.  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
sijiActullay in the boot directory of the natty vmlinux and initrd.img etc.. is 2.6.3906:58
sijiBut my uImage is for 2,6,3806:58
sijiwhether this will be the problem ?06:58
persiaMaybe, but only maybe.  More important than the contents of /boot are whether you have anything in /lib/modules/ that matches the currently running kernel06:59
sijilet me check07:00
sijioh right07:00
sijiall the modules are only for 2.6.3907:01
sijiSo either have to put 2.6.38 module there or ,hve to build new uImage for 2.6.3907:01
sijiRight ?07:01
persiaIf you want to be able to load drivers, yeah :)07:02
sijilet me give a try07:03
sijipersia, i guess it's detected now07:11
sijilights are cming from etehrnet card07:11
sijiTrying to configure it ..07:11
sijipersia, yes it's start working07:19
sijiEven my Wifi Module also detected07:19
* persia suspects mmcqd isn't supposed to consume more cycles than any other process08:01
infinity 1131 ?        D     51:39 [mmcqd]08:02
infinityThat's 10 days uptime on a system that's a full archive mirror.08:02
infinityIt's not the top offender, but it's close.08:02
persiaYou're clearly abusing your SD cards almost as much as I then08:03
infinity(If the mirror wasn't on external storage, it probably would be top)08:03
infinityWell, my root's on SD, cause I'm lazy.08:03
persiaThis is on a system with root on /dev/sda08:03
infinityOh.  Well, stop doing mean things to your CD cards.08:04
infinity(writing test images over and over?)08:04
persiaWorse: pieces of test images.08:04
* persia hopes to get to actual test images later.08:05
infinityI was supposed to be asleep, wasn't I?08:05
infinityI got distracted by Vi Hart talking about pie.08:05
infinityOr pi.08:06
infinityOr both.08:06
persiaMy views on timezones and sleeping habits being what they are, I'm not sure I'm qualified to answer that question.08:06
infinityI lost trach.08:06
infinitytrack, too.08:06
rsalvetippisati: ogra_: who is integrating the TI LT kernel at ubuntu?10:56
persiarsalveti: Last I knew it was ppsati10:57
persiaBut it was never clear to me if that was a LT kernel or a BSP kernel10:57
rsalvetithat's also what I want to know :-)10:58
rsalvetiwhat tree ubuntu is planning to use for omap 4, who is doing the work and how related it is with the TI LT tree10:59
ppisatirsalveti: bsp kernel, based on agreen's kernel-tilt/master11:10
ppisatiand here is if you want to try it out11:10
ppisatigit://kernel.ubuntu.com/ppisati/ubuntu-oneiric.git ti-omap4-next11:11
ppisatiif you want to tweak it11:11
rsalvetippisati: so, it's TI LT + ubuntu sauce?11:13
ppisationeiric/master + kernel-tilt/master + $omap4_only_stuff11:14
rsalvetihm, ok, we also want the same thing for linaro, so I'm thinking how should we avoid duplicate work11:14
ppisatiwhere omap4_only_stuff so far is only some config11:14
rsalvetiok, that's fine11:14
ppisatipick it entirely11:14
rsalvetiand in theory there's no reason to keep patches !config in $omap4_only_stuff11:15
rsalvetias agreen is taking most of the patches11:15
rsalvetijcrigby: so even less work for us atm11:16
rsalvetippisati: and when are you planning to push this to omap4 branch?11:17
ppisatirsalveti: well, there's one issue with audio still, but i think we can skip it ATM11:18
ppisatiif it gets some testing, i can push it next week11:18
ppisatibtw, IIRC exactly next week the SRU team open the window for new kernel cycle11:19
ppisatiso it's a perfect timing11:19
rsalvetippisati: cool, good to know11:21
ppisatiwhos is using omap4/panda?11:22
ppisatime, you, grue, ogra and janimo?11:23
janimoppisati, I do11:23
janimostock oneiric11:23
janimoupgraded from natty11:23
ppisatijanimo: cool, so can you give it a try?11:23
ppisatijanimo: http://people.canonical.com/~ppisati/ti-omap4-next/linux-image-3.0.0-1-omap4_3.0.0-1.0~9765dd1_armel.deb11:23
janimoppisati, sure11:24
ppisatiin the meantime...11:25
* ppisati -> lunch11:25
* janimo grumbles about canonicaladmin javascript bugs11:25
sijipersia, can u pls tell me abt where can I get pvr drivers for the kernel 2.6.3812:41
sijiis it bundled with omap ti Sdk ?12:42
persiasiji, You want https://wiki.ubuntu.com/ARM/OMAP/Graphics12:47
persiaI 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
sijipersia, ok12:48
persiaFor production shipment, it's worth double-checking the terms of your supplier arrangement with TI12:49
sijisure will do12:49
sijipersia, i have tried this link12:49
sijiit generated the driver only for 2.6.3512:50
sijinot for 2.6.3812:50
persiaYou installed libegl1-sgx-omap3 libgles1-sgx-omap3 and libgles2-sgx-omap3, and it didn't autocompile for your installed kernel?12:52
persiaWell, what did you do then?12:53
sijiit has created one more module folder at /lib/modules/2.6.35 and pvr folder created there12:54
siji2.6.35-n90  I guess12:54
sijiwhich is i think not compatible  with .3812:55
sijianyway let me give a try again12:55
sijipersia, Setting up linux-image-2.6.35-1-n900 (2.6.35-1.3.1) ...13:21
sijiRunning depmod.13:21
sijiupdate-initramfs: Generating /boot/initrd.img-2.6.35-1-n90013:21
persiasiji: Hrm?  Aren't you working on a Beagle derivative?  Why use the n900 kernel?13:23
sijiam not using actually13:24
sijiit by default installed13:24
persiaWhich image did you start from?13:24
persiaAs long as you start from one of the omap images, the n900 kernel shouldn't be installed.13:24
persiaThat's only default for the n900 images.13:24
chedderlooking for help finding the modules to enable networking13:24
chedderi am a newb - very cluness13:25
sijipersia, not getting you13:25
chedderi am running a pandaboard13:25
chedderI am using the 10.10 image, any thoughts13:25
persiachedder: does your uname -a match the contents of /lib/modules?13:27
persiasiji: 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
sijipersia, ko13:27
persiasiji: 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:27
sijipersia, got your point13:28
sijilet me recheck my rootstock parameters13:30
persiaIf 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:30
chedderummm no idea :)13:31
sijichedder, which kernel u are using ?13:31
sijiuname -a  will tell you that13:31
chedderI 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
persiachedder: 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:31
ogra_lool, around ?13:32
persiaIf you just booted that image, and waited for the resize, and went through the OEM wizard, networking should just work.13:32
chedderboth wired and wireless?13:32
persiaFor wireless, you might need to enable the TI PPA.  I forget (I only use wired on mine).13:33
cheddera working wired connection would be just fine13:34
persiaOK.  So there's two ways to make wired work.13:34
persia1) When you're done booting, use the network manager applet to select a wired network.13:35
persia2) read interfaces(5), and edit /etc/interfaces13:35
persiaOf these, 1) is *lots* easier.13:35
sijipersia, can pls have a look into my rootstock parameters @http://paste.debian.net/122989/13:38
persiaI'm not familiar with rootstock.  I used it once, a *long* time ago, and never liked it.13:38
sijioh ok13:38
persiaI'll look, but I don't promise much.13:38
sijino issues13:39
loologra_: half13:39
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
persiasiji: I'll recommend you use an Ubuntu kernel: try adding "linux-omap" to the seed list, and dropping the kernel0image line.13:40
persiaMind you, this may not actually work: I'm not sure what "kernel-image" does.13:40
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 upgrades13:41
sijipersia, will give a try13:41
ogra_lool, or do i misunderstand the code completely ?13:41
siji(building the image with "linux-omap" )13:43
loologra_: I don't remember that part anymore, it's possible that I didn't handle all cases13:49
persiarsalveti, 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 behavior13:50
=== zyga is now known as zyga-afk
loologra_: I think I had described this part of the problem in a separate message14:02
ogra_hm, k14:02
loologra_:  /etc/initramfs/post-update.d and /etc/kernel/postinst.d calls keep a14:05
lool note of which kernel initrd are being touched, and update14:05
lool /var/lib/flash-kernel/known-kernels with the data.  flash-kernel would14:05
loologra_: maybe I failed sending the etc/kernel snippet though14:05
ogra_i dont see it14:06
ogra_well, i think for now i'll go with a simple implementation in our flash-kernel14:06
rsalvetipersia: afaik, yes14:17
persiaOdd.  I don't see it in the archive.14:23
persiaIs it blocked on testers?14:23
sijipersia, till now everything is happening smoothly15:09
sijiI have made the image from rootstock , with 2.6.3815:10
sijiJust installing sgx packages15:10
sijinow it's only installing 2.6.38 header15:10
persiasiji, Heh, excellent.15:14
persiaRandom 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:14
sijipersia, yes it's starts working15:33
=== zyga-afk is now known as zyga
ogra_GrueMaster, some testing of my recent flash-kernel change for bug 701698 would be nice next week :)17:56
ubot2Launchpad bug 701698 in boot "update-initramfs -c does not update the bootloader" [High,Triaged] https://launchpad.net/bugs/70169817:56
GrueMasterOh, you actually fixed it?17:56
ogra_i worked around it, lool has a real fix but thats very complex17:57
ogra_with my fix it can happen that flash-kernel is run multiple times17:57
ogra_during one apt-get (dist-)upgrade  run if you have more than one kernel package you get17:58
GrueMasterOk, 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
ogra_its adding one file so SRU should be easy17:58
rsalvetimahmoh: GrueMaster: u-boot is correctly setting the mac address now21:01
rsalvetiand it's the same one detected by the kernel21:01
rsalvetijust booted here with pxe and it all went fine21:01
infinityrsalveti: \o/21:03
mahmohrsalveti: 2/2, thx!21:12
=== prpplague^2 is now known as prpplague
=== rsalveti` is now known as rsalveti
GrueMasterrsalveti: i'll test it once the IO tests finish, probably tomorrow.22:49

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!