**** BEGIN LOGGING AT Fri May 21 02:59:57 2010 May 21 07:10:04 morning May 21 07:12:32 hrw: Morning! May 21 08:00:29 udevd-event[1051]: udev_node_mknod: mknod(/dev/tty58.udev-tmp, 020660, 4, 58) failed: Operation not permitted May 21 08:15:03 udevd-event[1044]: udev_node_mknod: mknod(/dev/tty51.udev-tmp, 020660, 4, 51) failed: Operation not permitted May 21 08:16:56 cooloney: hey ... will we first get .34 omap? May 21 08:17:13 hrw wonders as he needs some driver ;) May 21 08:18:24 udevd-event[1051]: udev_node_mknod: mknod(/dev/tty58.udev-tmp, 020660, 4, 58) failed: Operation not permitted May 21 08:18:38 so far I have few network/usb devices: 7Mbps ethernet (x3), rt73usb (tends to disconnect from usb bus), ath9k_htc (802.11n dongle) May 21 08:19:14 chmod -R 777 /dev/capi" May 21 08:26:33 udevd-event[1051]: udev_node_mknod: mknod(/dev/tty58.udev-tmp, 020660, 4, 58) failed: Operation not permitted May 21 08:26:58 i using root nfs but udev occurs error May 21 08:27:01 udevd-event[1051]: udev_node_mknod: mknod(/dev/tty58.udev-tmp, 020660, 4, 58) failed: Operation not permitted May 21 08:27:37 when i flash the fs to the board .it's works well May 21 08:30:44 aaron_liuj: so check nfs settings May 21 08:31:36 asac: for 10.07, it will be .33 first May 21 08:32:11 cooloney: first? so in the end .07 gest .34 too? May 21 08:36:50 asac: 10.07 will always be .33 May 21 08:36:57 kk May 21 08:36:57 the patch from ti are based on .33 May 21 08:37:05 right May 21 08:37:08 i was talking aobut maverick May 21 08:37:22 so does that mean until we have 10.07 maverick stays on whatever we are using for .07? May 21 08:37:34 10.10 will be .35 finally, and we'll make available .34 kernels in the meanwhile May 21 08:37:51 asac: no, they are separate kernel trees May 21 08:38:37 mattieu will work on M kernel for omap3/omap4 mainline May 21 08:38:55 cooloney: I'm working on it, will be available early next week May 21 08:39:05 i will work on M kernel branch for omap4 patch dump May 21 08:39:15 amitk: great, so please talk with mattieu May 21 08:39:26 he is going to take a look at that May 21 08:39:31 sure May 21 08:39:35 thanks May 21 08:39:48 beagleboard netspeed is now only limited to usb-ethernet card speed May 21 08:39:48 * amitk & May 21 08:53:27 amitk: cooloney: we will provide .34 patches for M release May 21 08:53:44 guys - how likely is it to have a single kernel for >1 device by 10.10? May 21 08:53:54 hi ndec May 21 08:54:00 asac: hi May 21 08:54:03 s/more than >1 device/devices from >1 vendor/ May 21 08:54:15 >1 vendor? quite unlikely May 21 08:54:51 ndec: thanks, hah May 21 08:54:54 but you never know :) May 21 08:55:19 ndec: oh, one question May 21 08:55:26 cooloney: yup May 21 08:55:47 ndec: i got this in the dmesg May 21 08:55:50 'Uninitialized omap_chip, please fix!' May 21 08:55:50 asac, would it be possible to have a bunch of kernels on one 'image' and have uboot guess/choose the right one? May 21 08:55:56 ndec: but you'll also upgrade it to .35 as we go, right? May 21 08:55:57 did you guys see that? May 21 08:56:05 so that the 'impression' of getting integrated image is better than what we have today May 21 08:56:33 amitk: yes we will do that as well. basically our BSP team follow mainline dev. May 21 08:57:24 amitk: so we get regularly BSP rebase on latest mainline. we will need to discuss how we manage our out-of-tree patches for M releases. May 21 08:57:55 cooloney: on a9 only or also on a8? May 21 08:58:02 ndec: ok, then we are on the same page :) May 21 08:58:23 hrw: actually, i don't have hw, ogra_cmpc tested that on his blaze May 21 08:58:34 cooloney: i need to check. right now it's not in my dmesg buffer, so I will try to reboot when I am done with my builds May 21 08:58:34 zyga: you can have a bunch of kernels on the image and uboot selecting one .... the problem is that we cant have a single uboot for all boards May 21 08:58:42 cooloney: not have it on BB May 21 08:59:09 it should be omap4430 May 21 08:59:39 dual a9 May 21 08:59:49 cooloney: so blaze or panda - both are rather TI only (+few protos sent outside) May 21 08:59:58 asac, if the vendor would ship a boot loader that compatible with our boot requirements we might be able to pre-hint it with the right kernel to choose (that would only make sense if the vendors were interested in following this idea)\ May 21 09:00:27 amitk: the only tricky part is between now and july since we want an updated kernel for L and M releases ;-) May 21 09:00:33 hrw: exactly, i am just trying do some development based on the dmesg from ogra who has that hw May 21 09:01:15 cooloney: 374 void __init omap2_check_revision(void) in arch/arm/mach-omap2/id.c May 21 09:01:30 zyga: its difficult. not all boards can have a uboot preinstalled in flash (e.g. some dont have nand etc.) May 21 09:01:38 hrw: yeah, that is it. May 21 09:01:45 cooloney: looks like it did not found it as 4430 May 21 09:01:48 zygal: at least for omap, we are definetely interested in a single kernel image that supports all our boards. but this is tricky for now. May 21 09:02:02 hrw: https://pastebin.canonical.com/32503/ May 21 09:02:12 so there is more than just that. maybe if all would use disk/u-boot.bin.ARCH or something if they find that on mmc it would work May 21 09:02:20 hrw: but except that error message, others are looks good May 21 09:02:26 so weird May 21 09:02:32 cooloney: I saw that dmesg before May 21 09:02:36 asac, as long as arch is not arm-linux-eabi ;-) May 21 09:02:39 but thats not that simple either. i think for the time being we need to accept tht we need different boot parts May 21 09:03:06 and work on tools so you can more easily combine our filesystems with whatever boot things you need May 21 09:04:19 asac, your last comment is actually very true - a simple program that would download common filesystem image and combine that with whatever device kernel/boot requirements you may need would be good for early-adopters May 21 09:04:19 hrw: ah, enjoy that. hah May 21 09:04:58 cooloney: I can't access your pastebin with my launchpad account. is that expected? May 21 09:05:24 (with boot instructions/device pictures so that even most inexperienced early adopters/tinkers will get it right each time...) May 21 09:05:30 cooloney: If it's not confidential, please use paste.ubuntu.com :) May 21 09:05:31 * zyga stops daydreaming ... May 21 09:06:07 zyga: If you want a longer-term daydream, imagine devices shipping with a uboot that does the right thing already in flash, so that we just ship a kernel and it magically works :) May 21 09:06:48 persia, yes, that would be.... just like current PCs *g* May 21 09:06:54 (with less crap on screen) May 21 09:07:03 persia: a longer longer-term daydream would be a device that boots without the bootloader ;-) May 21 09:08:17 ndec: Depends on semantic values. My defintion of "bootloader" is "The thing that loads a kernel". I've no objection to it being in ROM, but I'll probably still call it a bootloader. I do have an objection to putting a kernel in ROM. May 21 09:08:47 persia, very true May 21 09:09:08 persia: ndec sorry, actually, it was posted by ogra_cmpc May 21 09:09:11 zyga: yep. thats the setup-sdcard.sh script atm. ... could be improved though May 21 09:09:14 persia, the really bad thing that I would hate is a bunch of devices shipping with bootloaders that load a signed kernel which cannot be changed ... May 21 09:09:19 cooloney: use pastebin.ubuntu.com May 21 09:09:36 cooloney: persia: no problem. i didn't know you had a private pastebin as well... May 21 09:12:09 asac: persia: can you confirm that if I create a new ubuntu package (for PPA upload), the right version number should be: my-pkg-0.1.2-0ubuntu1~ppa1? do you recommend that I put the -0ubuntu1 suffix? May 21 09:12:14 zyga: signed kernels are good. Not being able to configure the keyset is bad. Note that we currently distribute signed kernels in Ubuntu, and refuse to write them to flash if they aren't signed (although there are massive manual workarounds to let users do whatever they like)/ May 21 09:13:17 ndec: My recommendation is my-pkg (0.1.2-0ppa1) May 21 09:13:17 ndec: http://pastebin.ubuntu.com/437200/ May 21 09:13:41 ndec: your version number looks sane imo ...what persia said is also ok May 21 09:13:54 ndec: If the package *already* had an Ubuntu suffix, I'd suggest 0.1.2-3ubuntu4+ppa5 May 21 09:13:56 if the package isnt in debian the ubuntu1 suffix isnt needed May 21 09:14:22 persia: I am talking about new TI packages that aren't in debian or ubuntu already May 21 09:14:40 If/when it gets uploaded to Ubuntu, it will end up being 0.1.2-0ubuntu1, but it's safer to avoid messing with that for PPA versions, to give more flexibility. May 21 09:15:04 asac: so the 0ubuntu suffix will be needed if we ever put our packages in main/multiverse? May 21 09:15:04 persia: ppa1 is good too ;) ... May 21 09:15:19 well, i'd actually like to pull in everything we can as early as possible into maverick May 21 09:15:19 ndec: yeah ... unless you upload to debian May 21 09:15:25 ndec: For new packages, I generally use -0persia1 : it's been pointed out that I can do this because of how my nick sorts, so I recommend others use -0ppa1 to achieve the same goals. May 21 09:15:39 so using the -0ubuntu1 suffix should be preferred May 21 09:16:06 the suffix is not "needed". It's just the conventional notation to indicate how the package got into Ubuntu. May 21 09:16:19 i didnt say its needed but its more consistent May 21 09:16:37 ndec: in short ... your version number was perfectly fine ... will upgrade to ubuntu1 plain ... you can also use 0ubuntu0+ppa1 instead f 0ubuntu1~ppa1 ;) May 21 09:16:45 But, if the convention is followed, -0ubuntu1 should only be used for the revision that is actually uploaded to Ubuntu, and all prior versions should sort lower. May 21 09:16:55 asac, ++ May 21 09:16:56 persia: the suffix is needed to avoid syncs from debian if someone sabotages you and uploads the same package name there May 21 09:17:08 right May 21 09:17:15 I'm kinda curious where the ~ recommendation came from. I thought I changed all the LP docs to suggest + May 21 09:17:20 if you upload to debian all is fine May 21 09:17:29 I am looking for the *right* thing to do. looks like my initial proposal was ok, right? May 21 09:17:33 asac: no it isn't, but it does make that easier. May 21 09:17:44 persia: i am still in favour of that. its a matter what you are doing ... improvements to last version -> +xxx ... working on new version -> +1~xxx May 21 09:18:25 * persia fails to see a useful semantic distinction between improving the old revision and working on a new revision, but has little interest in debating the specifics :) May 21 09:18:47 persia: i use ~ppa1 for my initial attempts.. i want my first official package to be 0ubuntu1+ppa1, but for all my initial attempts I am using ~ppa1 until i have something I am happy with May 21 09:18:50 persia: its a matter of guts feeling ;) May 21 09:18:55 ndec, pastebin-> sorry i'm not sure about how much i'm allowed to make public about the blaze yet so i usually use the protected pastebin May 21 09:19:06 ndec: In short, you can use any version you like. For an ideal end-user upgrade experience from PPA to Ubuntu, be sure to use something that dpkg --check-versions believes is lower than -0ubuntu1 May 21 09:19:29 (and i usually dont paste the url in public channels :P ) May 21 09:19:29 ndec: 0ubuntu1+ppa1 would be wrong ... as that wouldnt upgrade to 0ubuntu1 which would be that goes to the real archive ;) May 21 09:20:02 just use 0ubuntu0+ppa1, ppa2, ppa3 (even if 3 is final) ... or 0ubuntu1~ppa1, ppa2, ppa3 ... May 21 09:20:09 right May 21 09:20:12 both would move towards a 0ubuntu1 for the real archive May 21 09:20:21 ogra: morning, May 21 09:20:22 in maverick we'll just use -0ubuntu1 then May 21 09:20:25 hey cooloney May 21 09:20:34 * persia thinks -0ppa1 is easier to type than -0ubuntu0+ppa1 :) May 21 09:21:19 ndec, go with asac's suggestion May 21 09:21:25 i replied one email for you and prepared a new kernel with omap serial built-in for testing May 21 09:21:42 cooloney, great, will test soon May 21 09:22:03 i wonder how that works since the early messages seem to go to ttyS* by default May 21 09:23:31 asac: persia: ogra: thanks. I will continue with what I have, e.g. tisyslink-lib_0.24.5-0ubuntu1~ppa1, and I won't use the +ppa1 unless I want to override the main archive... May 21 09:24:44 ogra: blaze is public platform. its BSP is also on public trees. so all is fine. May 21 09:24:52 cool May 21 09:25:02 i'll use the public pastebin from now on :) May 21 09:25:17 i'm always a bit over-anxious with that stuff :) May 21 09:26:18 ogra: are you able to boot a ubuntu image on blaze? May 21 09:26:24 sure May 21 09:26:36 its my main build platform now :) May 21 09:26:45 which chroot do we use for building arm kernels? *-amd64 or *-i386 May 21 09:27:00 ogra: oh, build platform, native building May 21 09:27:03 lag, -armel May 21 09:27:14 cooloney, indeed May 21 09:27:19 ogra: same for me. this is actually quite cool... May 21 09:27:29 i'm currently working on x-loader and u-boot for the blaze May 21 09:27:45 ogra: Doesn't exist on emerald? May 21 09:27:49 its a bit painful that the x-loader tree links hard into the u-boot tree for all the headers May 21 09:27:58 lag, whats emerald ? May 21 09:28:08 kernel porter box ? May 21 09:28:09 ogra: I thought you were going to say that :) May 21 09:28:13 apw: --^ May 21 09:28:22 ogra: i know... but we will soon get rid of xloader anyways... May 21 09:28:43 lag: Probably not. People who use that server were surprised that they work at UDS. May 21 09:28:48 ndec, indeed, but currently i need it so i need to somehow build it :) May 21 09:28:49 ndec: so bootrom -> uboot-from-sd? May 21 09:29:21 or even s/uboot/whatever May 21 09:29:36 persia: What do you mean? May 21 09:29:46 hrw, http://omappedia.org/wiki/E-MMC_boot see the bottom May 21 09:29:55 hrw: yes. we can append a small header to bootloader with EMIF config. ROM code parses header, configures DDR, and then loads uboot from SD (or NAND, or eMMC) in to DDR. so no more xloader May 21 09:30:45 lag: At the end of the schroot+LXC session there was a demo of running an -armel chroot on an amd64 machine, which was the first time some of the present kernel folk had seen that. May 21 09:30:49 hrw: there is a limitation today with OMAP4, that will be fixed in next silicon rev. May 21 09:31:07 I love that 'next silicon rev' part ;D May 21 09:31:14 lol May 21 09:31:20 Ah, I see May 21 09:31:39 I have already done it, but I can't remember which chroot I used May 21 09:31:45 I thought it was amd64 May 21 09:31:59 persia: armel chroot on x86 machine: can we build any armel packages this way? May 21 09:32:16 I own atmel board with CPU rev.A which mean "boot only from dataflash". rev.B boards (which are most of sold ones iirc) can boot from dataflash or nandflash. the funny part is that dataflash is provided as mmccard May 21 09:32:31 ndec, you can but note that its not faster than using qemu VMs ... compiler is as slow as emulated May 21 09:32:47 the only thing you speed up is all the surrounding stuff May 21 09:32:53 ogra: ok.. so I will continue to use my board. May 21 09:32:56 yeah May 21 09:33:09 * ogra loves to be able to use make -j2 :) May 21 09:33:22 ndec: No, but you can build most of them. I've never had a build succeed in that environment that didn't also succeed on the buildds, but I've had some fail. Anything that relies on a real /proc tends to break, so mono definitely won't work. Some parrot stuff doesn't work right, etc. There are also some missing syscalls, so some other stuff doesn't work. May 21 09:33:54 * ogra thought we had all syscalls after the last release May 21 09:34:13 there are some missing ioctl calls though May 21 09:34:36 ogra: I thought we had all the syscalls that we knew broke builds we'd tested, rather than having done a formal evaluation of all possible syscalls, but you may be right. May 21 09:35:03 well, i havent seen any "unsupported syscall" message in 6 months May 21 09:35:08 ogra: i can't sign my packages on the board since I am mount my rootfs over NFS. and my $HOME is not on a secure location. so I don't want to put my keys there. can I sign the .dsc and .deb afterwards after copying them on my laptop? May 21 09:36:07 yes, you should be able to use debsign or just unpack the tree on your x86 and use dpkg-buildpackage -S -sa May 21 09:36:09 ndec: `debsign -r` lets you sign anythng you can scp from and to. man debsign for details. May 21 09:36:42 To save on warning messages, I always use `debuild ... -us -uc` when building something for debsign -r May 21 09:36:42 * ogra often uses the latter as an additional control point that the source package builds right on other arches May 21 09:37:24 persia: ogra: ok, I will try that. btw, I am using dput over scp to copy the *.changes, that works great. May 21 09:37:47 cool May 21 09:37:54 i never tried that May 21 09:39:04 ogra: we setup an internal debian archive, so that we can apt-get install our early packages (without launchpad). so we build .dsc and .deb on boards, and update the debian archive with dput! May 21 09:39:23 sweet May 21 09:40:02 ogra: I realized that when you build with 'debuild' the .changes file tracks the .deb, so dput will also upload the .deb May 21 09:40:23 yeah May 21 09:40:41 wont work with the real archive though :) it only accepts sources May 21 09:40:56 i think debian allows binary uploads though May 21 09:41:09 ndec: I'll strongly recommend you don't do that. We chose to use source-only uploads in Ubuntu for several reasons, not least of which is that you can end up with problems rebuilding a package because of stuff that is installed in your local machine when using debuild to construct a .deb May 21 09:41:30 ogra: Rather, Debian requires binary uploads, supposedly as proof that the source is known to build somewhere. May 21 09:42:55 persia: i am not talking about a production system here. i need to be able to share .deb within the teams so that anyone can apt-get install TI stuff. so the workflow is: 1) I build source and bin package on my board, 2) dput to the archives, 3) any user can use my .deb.... this is cool for early dev. May 21 09:43:39 ndec: I understand. I still recommend you use sbuild or pbuilder to do that. This will produce an armel.changes file which you can also dput. May 21 09:44:36 The problem is that if you end up having something odd on your machine that isn't listed in the control fields, you may end up with a different .deb than you expect, or it may work for you when testing, but then not work for anyone else later. May 21 09:44:58 This doesn't always happen, but these are examples of the sorts of issues that have been encountered with that type of workflow. May 21 09:45:18 (and avoiding these issues is part of why sbuild and pbuilder are available in the archives) May 21 09:46:42 persia: you mean running sbuild on the OMAP4 board, to make sure that my control fine has all the proper deps? May 21 09:46:56 Precisely. May 21 09:46:59 persia: what are the diffs between sbuild and pbuilder? May 21 09:47:26 Completely independent development histories, and different ways to add hook scripts, modify the internals, etc. May 21 09:47:46 Both attempt to replicate what is considered an ideal build environment, and so do almost precisely the same thing. May 21 09:48:36 I personally use sbuild. I know lots of folks that use pbuilder. My recommendation is always to use the one that seems least confusing (although I'm only able to help people setup/use sbuild on schroot) May 21 10:05:48 ogra: does that ttyO2 ~test4 kernel work on your side? May 21 10:22:28 cooloney, still garbage May 21 10:23:12 oh, wait i used O0 not O2 May 21 10:23:55 cooloney, any FYI it boots through, i get a login prompt on the LCD May 21 10:25:25 cooloney, works :D May 21 10:29:04 Ubuntu 10.04 LTS blaze ttyO2 May 21 10:29:04 blaze login: May 21 10:29:06 :) May 21 10:29:47 cooloney, so now we only need to get rid of the "omap_hwmod:" messages and we should be roughly fine May 21 10:30:08 ndec, do you have an idea why we get all the spam ? May 21 10:30:56 massive amounts of omap_hwmod: lines are put out ... according to the prefix <7> its loglevel 7 but if i change it it doesnt change behavior May 21 10:31:43 ogra; do you have these traces in serial console or in dmesg? May 21 10:31:52 everywhere May 21 10:32:12 and it goes on to spill to console after boot May 21 10:32:24 <7>omap_hwmod: i2c1: enabling May 21 10:32:25 <7>omap_hwmod: i2c1: idling May 21 10:32:36 thats what i see after boot in dmesg and console May 21 10:32:46 ogra: i don't have them in serial console. but I am not using same kernel as yours. probably something wrong with the config of cooloney's kernel May 21 10:32:55 during boot it points to different devices May 21 10:33:17 well, its the omap4 config merged with the ubuntu config May 21 10:33:25 something seems to clash there May 21 10:33:58 ndec, also are you able to run git clone with your kernel ? May 21 10:34:14 for me it fails and afterwards nearly everything starts to segfault May 21 10:34:23 ogra: nope... i think i mentioned that to you on irc a few weeks back May 21 10:34:31 ah, k May 21 10:34:45 robclark said he heard someone found a fix for it May 21 10:34:56 ogra: i have the same problem. I installed an older version of git (1.6.5) which works. May 21 10:35:01 right May 21 10:35:07 rob told me the same May 21 10:35:28 ogra: i think this is just a rumor of a fix... i haven't seen anything.. May 21 10:35:28 ndec and ogra, i am working on killing omap_hwmod May 21 10:35:36 omap_hwmod message May 21 10:35:44 cooloney, perfect May 21 10:35:54 ndec, and rebooting seems to fail for me May 21 10:36:00 cooloney: ok... please don't kill omap_hwmod ;-) May 21 10:36:00 not sure thats known already May 21 10:36:11 ogra: but still don't have any idea. May 21 10:36:27 ogra: known issue as well. and you must reboot after git clone fails. May 21 10:36:28 ndec: eheh, indeed. that's our rumtime PM, right May 21 10:36:38 ndec, heh, yeah :) May 21 10:39:38 cooloney: amitk: by the way, CONFIG_ARM_THUMB should be checked in config/enforce for 10.04 and above... it's a strong requirement. May 21 10:41:47 cooloney: in arch/arm/mach-omap2/omap_hwmod.c you have #define DEBUG at b/o file. that should be the problem, no? May 21 10:41:51 asac: http://hrw.pastebin.com/ucXSuQU0 May 21 10:43:17 hrw: this looks sweet... May 21 10:43:28 pure sh May 21 10:43:33 hrw, urgh May 21 10:43:36 use case ! May 21 10:43:45 hrw: still sweet ;-) May 21 10:43:55 ndec: ok, we enable it in our ARM. May 21 10:44:00 but not in enforce. May 21 10:44:03 ogra: no more need for ttySx.conf files May 21 10:44:06 i will post a patch May 21 10:44:36 ogra: the script detect your console args from bootargs and create the correct getty May 21 10:44:43 ARM_THUMB is a thing which should be always enabled in kernel (on 920t and above) May 21 10:44:47 for x in $(cat /proc/cmdline); do May 21 10:44:48 case $x in May 21 10:44:48 console=*) May 21 10:44:48 tty=${x#console=} May 21 10:44:48 log_begin_msg "$DESCRIPTION" May 21 10:44:48 cat > /root/etc/init/${tty}.conf < start on stopped rc RUNLEVEL=[2345] May 21 10:44:52 stop on runlevel [!2345] May 21 10:44:54 respawn May 21 10:44:56 exec /sbin/getty -L 115200 ${tty} vt100 May 21 10:44:58 EOF May 21 10:45:00 ndec, hrw ^^^ May 21 10:45:01 cooloney: you can have arch specific enforce. we should add it to our enfore May 21 10:45:14 ogra: what if my board has 57600 serial only? May 21 10:45:25 ogra: but I like your ver May 21 10:45:27 ndec: found that DEBUG macro. there May 21 10:45:30 hrw, add a nested case that catches the speed :) May 21 10:45:40 ndec: let me remove it and build the kernel again. May 21 10:45:55 hrw, its just a quick hack, needs test code etc May 21 10:45:57 ndec: but i think it is the same in omapzoom git tree May 21 10:46:39 amitk: right, i found most of the omap enforce are the same as our common enforce May 21 10:46:44 .master enforce May 21 10:46:45 cooloney: yes. i have all traces in dmesg but not in console. what are your bootargs? May 21 10:46:53 hrw, note that my code lives rather in initramfs for a proper upstart script you need the right upstart script commands May 21 10:47:25 hrw: your script looks good May 21 10:47:28 hrw, though when scripting, try to rather use case than if its several times faster May 21 10:47:33 have you tried it with a few options? May 21 10:47:47 ogra: we dont want to patch existing ttys May 21 10:47:57 its really just creating the right tty on the fly May 21 10:48:05 for non casper boots May 21 10:48:21 asac, yes thats what my script does, you just need some test for ttyS May 21 10:48:33 thats why i said above its a quick hack :) May 21 10:48:51 by default nothing ships ttyS scripts May 21 10:48:59 ndec: i don't have hardware, so i don't change any bootargs, May 21 10:49:04 ogra: ^^^^ May 21 10:49:07 hrw: can you use ogras approach and clean that up a bit ... so it parses the number etc May 21 10:49:13 hrw: or are you happy with your current approach? May 21 10:49:23 http://hrw.pastebin.com/CuT5AM1z is a bit cleaner May 21 10:49:24 hrw: also remember to use autologinroot there as the login May 21 10:49:49 ndec, root=UUID=bc59dc33-8403-4fbd-84a6-ddf0c760b25a ro quiet console=ttyO2,115200n8 vram=12M omapfb.vram=0:5M,1:5M fixrtc May 21 10:50:41 asac: autologinroot? May 21 10:50:41 one thing to handle left May 21 10:50:52 * ogra needs to feed the cats else they will eat *me* May 21 10:50:55 cmdline="console=tty1 console=ttyS2" May 21 10:51:09 hrw: we should ignore ttyX if /etc/init/ttyX.conf exists May 21 10:51:21 asac: thats next to add May 21 10:51:25 right May 21 10:53:04 ndec: thats an auto login as root thing. for a minimal image May 21 10:53:10 ogra: ok, after you feed your cats, you will get a new kernel to test May 21 10:54:51 is console=/dev/ttyXXX also valid? May 21 10:54:53 i think so May 21 10:55:05 hrw: in that case remember to strip the /dev/ or so in your script May 21 10:57:04 ok May 21 10:58:26 cooloney: you need to revert 2d60cfb9010470ce5b172513c907091ad30be34e, http://dev.omapzoom.org/?p=integration/kernel-omap4.git;a=commit;h=2d60cfb9010470ce5b172513c907091ad30be34e. i will check why this ended up in our tree... May 21 11:02:59 asac, i dont think its valid May 21 11:03:20 cooloney, i'm back (surrounded by burping cats now :) ) May 21 11:03:35 ogra: kk May 21 11:27:59 ndec, bah, the hole for HDMI on the blaze case needs to be bigger, i have about 10 HDMI cables of different size here, not a single one fits through the hole in the case ! May 21 11:30:15 oh, silly me its micro HDMI May 21 11:31:02 * ogra gets the right cable May 21 11:33:24 ogra: pls try my ~test5 kernel in the same URL May 21 11:33:59 * ogra wgets May 21 11:34:15 Which revert the DEBUG macros May 21 11:39:59 cooloney, ndec, http://paste.ubuntu.com/437259/ \o/ May 21 11:40:18 ogra: cool May 21 11:40:31 ogra: lol May 21 11:44:05 hmm, i wonder whyt happens if i dont set the vram options May 21 11:45:16 i think we should really set proper defaults in the kernel so we only need the cmdline option to override them May 21 12:13:21 asac: what handle autologinroot? May 21 12:18:12 current version of service has 48 lines, handles /dev/ttyS2 and ttyS2, uses cases, checks for services May 21 12:18:36 http://hrw.pastebin.com/4VZGsknt May 21 12:20:12 * ogra bets line executing 15 is slower than just keeping line 17 alone May 21 12:20:21 *executing line 15 May 21 12:21:24 right May 21 12:21:30 also does upstart like exit 0 ? May 21 12:21:41 I took it from other init script May 21 12:21:46 ah, k May 21 12:21:50 i wasnt sure about that May 21 12:55:10 hrw, how about that one :) http://paste.ubuntu.com/437306/ May 21 12:56:04 (indeed without the echo around the getty call) May 21 12:57:25 ;) May 21 12:57:42 ogra: http://hrw.pastebin.com/XAvmFiA8 landed in package May 21 12:58:12 yup May 21 12:58:13 but yes - I like your version May 21 12:58:32 and it does not work on many ARM boards May 21 12:58:38 ttyAM0 ttyAMA0 May 21 12:58:39 why is that ? May 21 12:58:43 ttySAC0 May 21 12:58:44 oh, right May 21 12:59:21 but case: tty([0-9]+) {} should take care May 21 12:59:25 should rather be tty[A-Z]*) in the case May 21 13:00:12 or that May 21 14:13:41 ogra: what was the hint that told ubiquity on a live cd what packages not to include in the install? May 21 14:14:39 ah ... thats ./binary/casper/filesystem.manifest-desktop May 21 14:48:41 prpplague: hi May 21 15:01:39 hrw: hey bud May 21 15:02:03 prpplague: any rumours when pandaboard will hit market? May 21 15:02:50 hrw: yea, but i'm not if the info can be released May 21 15:02:55 i'll ask about that May 21 15:46:53 http://www.flickr.com/photos/hrwandil/4506971517 May 21 15:49:12 hrw: any plans for what sw / UI to be running on that? Remote control? May 21 15:49:35 robclark: for now it is just machine for live-helper and other such things May 21 15:50:04 robclark: I planned to make beagleboard tv but so far did not get good working wifi May 21 15:50:12 ahh May 21 15:50:41 hrw, with the ubuntu kernel ? May 21 15:51:01 ogra_cmpc: previous was with 2.6.32 from ti-psp May 21 15:51:08 ah May 21 15:51:23 i yet have to find a usb wlan stick that doesnt work on ubuntu May 21 15:52:32 ogra_cmpc: tplink TL-WN721N? May 21 15:52:47 ogra_cmpc: it is 802.11n, needs ath9k_htc driver May 21 15:53:02 FATAL: Module ath9k_htc not found. May 21 15:54:20 grmbl May 21 15:54:37 ogra_cmpc: FATAL: Module ath9k_htc not found. May 21 15:54:51 ogra_cmpc: it is in wireless tree May 21 15:54:57 weird May 21 15:55:24 http://hrw.pastebin.com/hDCp05fH - known? May 21 15:55:29 all USB wifi drivers should be enabled in out omap kernel May 21 15:55:35 if not thats a bug May 21 15:55:45 ogra_cmpc: all existing in mainline, yes May 21 15:56:24 hrw, we got a thread on linux-omap about dss/core.c:323! ... no fixes yet.. May 21 15:56:35 hrw, trying to shut down the board while DPMS is active ? May 21 15:56:57 ogra_cmpc: no just "reboot" command May 21 15:57:03 i only get that if the screen is off May 21 15:57:12 as long as its on it reboots fine May 21 15:57:17 ogra_cmpc: I do not checked does lcd is on or off May 21 15:57:25 probably off as I do all over serial+ssh May 21 15:57:26 so imho its a DPMS vs DSS2 issue May 21 15:57:33 right May 21 15:58:00 we have a bug about it open somewhere May 21 15:59:01 bug 563650... still occurs with 2.6.34 + dss2 next... May 21 15:59:03 Launchpad bug 563650 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "DSS2 oops when shutting down while DPMS is active (affects: 1) (heat: 10)" [Medium,Confirmed] https://launchpad.net/bugs/563650 May 21 15:59:06 https://bugs.edge.launchpad.net/ubuntu/lucid/+source/linux-ti-omap/+bug/563650 May 21 15:59:07 Launchpad bug 563650 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "DSS2 oops when shutting down while DPMS is active (affects: 1) (heat: 10)" [Medium,Confirmed] May 21 15:59:12 bah rcn-ee beats me :P May 21 15:59:33 it's one i'm playing source wise with right now.. ;) May 21 15:59:59 nice ! May 21 16:00:35 ok, rt2570 and rt3070 refuse to work May 21 16:00:53 rt3072 May 21 16:01:27 rt2570 gets connected/disconnected and loop May 21 16:02:33 do you have linux-firmware installed ? May 21 16:03:29 yes, firmwares exists May 21 16:03:37 anyway end of day for me May 21 16:03:40 hmm, make sure to file bugs for all of them May 21 16:03:50 have a nice weekend May 21 16:03:53 will May 21 16:04:05 you too May 21 17:29:24 hi chaps, anyone got any experience running Ubuntu on the Beagleboard? May 21 17:30:37 Cosmo`, https://wiki.ubuntu.com/ARM/Beagle May 21 17:30:51 thanks ogra_cmpc, i've actually already got it up and running via the netinstall May 21 17:30:54 which is actually really good May 21 17:31:01 but i'm experiencing some strange behaviour May 21 17:33:45 (i am still working out exactly what's going on bear with me for half hour ;) ) May 21 17:40:02 it seems that whenever i do anything intensive over the USB the whole thing just trashes itself May 21 17:40:11 the USB hub powers down May 21 17:40:32 you should always use a powered hub with a beagle May 21 17:40:37 i am May 21 17:40:54 however ... i have an idea May 21 17:40:55 one sec May 21 17:40:55 what board revision is that ? May 21 17:41:06 C3 i think May 21 17:41:11 hmm May 21 17:41:39 i havent seen issues like that with the C4, not sure about the C3, rcn-ee might know about that rev May 21 17:41:40 (jumps back in)... Cosmo` is this over ehci? there is a known issue with load on C2/3's.. May 21 17:41:53 heh May 21 17:41:55 (hence the C4 ehci power redesign) May 21 17:42:03 if i'm honest May 21 17:42:06 i have no idea May 21 17:42:30 it's labeled.. next to the usb 2.0 (ehci) connector... ;) May 21 17:42:59 no i mean i know it's C3 May 21 17:43:07 but i don't whether it's over ehci May 21 17:43:59 hmm May 21 17:44:02 i think this MIGHT be the problem May 21 17:44:04 one sec May 21 17:44:34 oh sorry... the OTG port (little one next to the 5.0volt) is usually called "MUSB" and the regular usb 2.0 port is called "EHCI" mostly becuase it doesn't support old Usb1/1.1.. (ehci only) May 21 17:45:31 there is a cap mod listed in the beagleboard forums, but most people just use the MUSB port by default on C2/3's... May 21 17:45:49 hmm, not seeing anything that says EHCI May 21 17:46:00 interesting May 21 17:46:07 the std. sized USB socket is ehci May 21 17:46:16 i tried powering from the USB OTG just then from my PC and not from the hub May 21 17:46:16 same issue May 21 17:46:39 however May 21 17:46:45 it gets rid of alot of the weird USB errors i was having May 21 17:46:46 Cosmo`, http://elinux.org/BeagleBoard#EHCI talks about the hardware issue.. May 21 17:46:53 right, thanks let me take a look May 21 17:47:39 * rcn-ee goes back to beer and grillin.. ;) May 21 17:47:43 ok, that certainly looks plausible May 21 17:47:50 doh, now i need to get one of those special OTG connectors May 21 17:48:38 is there any way you can force it in software to be a host without using one of the special connectors? May 21 17:49:21 a power supply should hlep too, no? May 21 17:49:39 yep, i will need to use one if i am using the USB OTG as a host May 21 17:49:59 at the moment i am powering it from the USB OTG, but i can run back up to the lab and get a power supply May 21 19:14:31 hmm May 21 19:14:49 there's an aggrevating lack of places to buy USB OTG cables in the UK May 21 19:17:32 yeah they've always been hard to find... you can find them at cell phone stores for nokia phones... look like: http://search.digikey.com/scripts/DkSearch/dksus.dll?lang=en&site=US&KeyWords=10-00003-ND May 21 19:18:28 or if you have an atmel avr8/32 development kit, they usually throw one in their too... May 21 19:19:31 well rcn-ee May 21 19:19:41 do you know if i can just force the port into host mode in software? May 21 19:20:25 yeah it's just a config option, you you'll have to rebuild... May 21 19:21:01 because i don't see why i couldn't just use a Mini-B to USB May 21 19:21:05 and plug it into a powered hub May 21 19:21:08 would that work? May 21 19:21:25 yeah it would work.. as long as you jumper the two pins on the beagle.. May 21 19:21:36 oh, so it cannot be done without hardware modification then? May 21 19:21:41 as i can't modify this board May 21 19:21:56 you can either do a software change (config in kernel) or hardware change.. May 21 19:22:04 ah, ok May 21 19:22:17 well i've got no problem with rebuilding the kernel, i'll do it that way May 21 19:22:33 the board doesn't belong to me, i've borrowed it from our research group May 21 19:23:34 is there anything special to know for the ARM kernel or can i just follow standard Ubuntu kernel compilation tutorials? May 21 19:23:47 actually as long as you don't need it at boot.. you might be able to play with: /sys/devices/platform/musb_hdrc/* May 21 19:24:33 my Bx beagle has "cat /sys/devices/platform/musb_hdrc/mode" ->a_host May 21 19:24:48 hmm ... i could try this May 21 19:24:57 i will have to go to the lab and get an adapter first though May 21 19:25:26 with everything on the otg bus, you'll need a serial cable to gain console access to bring it up.. May 21 19:25:50 well i'll just plug a keyboard in on the EHCI port May 21 19:25:58 that doesn't seem to be enough to crash it all May 21 19:26:17 and i can plug it into a monitor so i can make the changes directly May 21 19:26:25 it's high bandwith devices.. usb harddrives/usb ethernet that usually casue it for mine.. May 21 19:26:42 so do i just echo a_host into mode May 21 19:27:00 yeap.. do it as root.. (sudo su) May 21 19:27:07 well hold on, i'll pop to the lab and get an adapter first anyway, can't do anything without that May 21 19:27:11 be back in 20 minutes or so May 21 20:08:32 well May 21 20:08:34 great success May 21 20:08:38 let's see if i can get this working May 21 20:12:18 hmm rcn-ee ... i don't seem to be able to get permission to echo into mode in musb_hdrc May 21 20:13:23 yaep.. you have to use 'tee' or switch to root.. "sudo su" then do it.. May 21 20:13:45 interesting May 21 20:13:47 not used ubuntu before May 21 20:13:56 so never had to do 'sudo su' :) May 21 20:14:09 basicly sudo echo "x" > 'y' doesn't work. ;) May 21 20:14:33 hmm ... May 21 20:14:49 i get a write error with an invalid argument when using "echo 'a_host' > mode" May 21 20:16:56 weird.. just try 'host' not sure why mine is a_host but it's what google shows May 21 20:17:12 odd May 21 20:17:13 that worked May 21 20:17:19 well May 21 20:17:23 when you read back is it host or a_host? May 21 20:17:24 it goes straight back to b_idle anyway May 21 20:18:10 it doesn't error though May 21 20:22:42 So, one should generally not `sudo su`. In almost all cases, `sudo -s` is preferable. For redirects, something like `cat foo | sudo tee output.file` is the common solution (only writes the file as root, and keeps the process running as non-root) May 21 20:23:18 right May 21 20:23:27 i'm used to using other distributions so typically i would usually just sudo May 21 20:23:40 and then simply su when it's needed (rarely) May 21 20:28:54 oops May 21 20:43:46 i guess you just can't do it in software on the beagleboard May 21 21:08:41 so rcn-ee, i guess the only option for software will be to recompile the kernel May 21 21:14:57 any pointers on where to look for how to do this? **** ENDING LOGGING AT Sat May 22 02:59:57 2010