**** BEGIN LOGGING AT Thu Nov 04 02:59:57 2010 Nov 04 08:42:19 moin Nov 04 08:45:19 moin Nov 04 08:47:21 rsalveti: yes, will do the test. Thanks for reminding me! Nov 04 09:29:17 rsalveti: found issue. natty initrd was wrong - replaced with maverick one and got it booted Nov 04 09:29:41 total used free shared buffers cached Nov 04 09:29:41 Mem: 993492 120172 873320 0 18744 62900 Nov 04 11:16:13 hrw: cool, I don't think natty is tested already Nov 04 11:20:16 yep Nov 04 11:28:11 hrw, saw the same thing on my beagles, something's wrong with natty's unitrd generation... Nov 04 11:31:05 thx Nov 04 12:02:02 Hi all Nov 04 12:02:16 Does OpenOffice.org work on Ubuntu 10.04 for ARM? Nov 04 12:02:24 or 10.10 for that matter... Nov 04 12:03:35 don't have it in front of me right now, but I believe it works fine Nov 04 12:04:48 dmart: thx Nov 04 12:15:14 rsalveti: Hi! I am trying to get the ubuntu 10.10 image on TI SDP omap4 to work. Unfortunately the installer crashes so I can't continue graphically. Furthermore I can't get any external mouse/keyboard to work :(. Any ideas how I can get a login prompt on the serial console? Nov 04 12:15:45 alf_: hm, did you try the blaze files? Nov 04 12:16:03 alf_: https://wiki.ubuntu.com/ARM/OMAPMaverickInstall Nov 04 12:16:46 rsalveti: Yes. I copied them to the boot partition. I also added console=/dev/ttyO2... I have console output but no login. Nov 04 12:16:48 alf_: problem is that the pre-installed image doesn't have any user, and expect the user to create one at the oem-config screen Nov 04 12:17:21 alf_: to have login you'll need to create one user (mounting at your host, and using chroot + qemu for example), and create the ttyO2 file at /etc/init Nov 04 12:17:51 then upstart will call the proper getty Nov 04 12:18:05 rsalveti: ok, I will try that. Thanks! Nov 04 12:18:09 but seems weird that you don't have any mouse and keyboard Nov 04 12:18:26 alf_: http://paste.ubuntu.com/525611/ Nov 04 12:27:10 ndec1: vstehle: do you know any hw difference that would make the omap 4 sdp board behave differently than blaze? Nov 04 12:27:31 alf_ currently got an sdp to work with, and I never saw anyone using and booting with current sw Nov 04 12:42:52 rsalveti, I wonder if alf_ is using an ES2.x to begin with... Nov 04 12:43:01 vstehle: hm, true Nov 04 12:44:46 alf_, you can login as root if you manually edit /etc/shadow and remove the '*' or '!' in the root password. Not recommended for a real system, but for debug it can help. Nov 04 12:46:13 vstehle: thanks. How can I tell if I have ES2.x? Nov 04 12:53:07 alf_: do you have "OMAP4430 ES2.0" at your dmesg? Nov 04 12:53:37 don't remember if the code is correct, but I believe it is at least to detect if it's 2.x or 1.x Nov 04 12:54:27 rsalveti: yes I do have "OMAP4430 ES2.0" Nov 04 12:54:43 rsalveti: and now I have a login :) Nov 04 12:57:34 alf_: problem is that the code to identify if it's an es2.0 is not that reliable, the default when it can't find the proper id is to assume it's using the latest one Nov 04 12:58:25 rsalveti: I also see an ES2 GP sticker on a chip Nov 04 12:58:41 that's better :-) Nov 04 13:00:22 rsalveti: vstehle: ndec1: for anyone who is interested my dmesg output is http://paste.ubuntu.com/525642/ Nov 04 13:00:57 when I plug in a usb device nothing happens :( (eg no dmesg output) Nov 04 13:01:17 I have tried all 3 usb ports (hi-speed, full-speed, OTG) Nov 04 13:02:18 Anyone with experience with PulseAudio on OMAP3? Nov 04 13:03:01 I am considering using PA vs. ALSA for an application (generating 8channels of 24-bit@48kHz) Nov 04 13:03:10 alf_: hm, you should have at least touchscreen and keyboard working Nov 04 13:03:26 don't know about usb, don't know if it worked on blaze Nov 04 13:04:08 I don't think the smsc chip available at panda is also integrated at the sdp Nov 04 13:04:46 rsalveti: yes touch and onboard keyboard works... but they are a pain to use :S I can't even find how to backspace on that keyboard :P Nov 04 13:05:02 haha :-) Nov 04 13:08:50 alf_: touch screen and keyboard can at least help you finishing the pre-installed image boot Nov 04 13:09:12 now for usb maybe vstehle knows better Nov 04 13:11:12 rsalveti: Unfortunately the installation crashes and I can't read the message because it is insanely difficult to resize the window using the touch screen Nov 04 13:11:28 hm, ok Nov 04 13:12:51 rsalveti: in any case, I am pretty happy having console and ssh access (hopefully) for now Nov 04 13:23:46 rsalveti, If I recall correctly, the USB on SDP will be in "slave" mode. Not what alf_ wants to connect a mouse. Nov 04 13:23:59 Alternatively, synergy2 may help here :) Nov 04 13:24:27 Log through UART, connect to network, install synergy, finish installer with PC keyboard and mouse. Nov 04 13:26:12 vstehle: interesting, I 'll give that a try later :) Nov 04 13:26:24 vstehle: got it Nov 04 13:26:29 yeah, over network can help :-) Nov 04 15:15:30 rsalveti: after installing omap4 drivers, when starting X I get "(EE) AIGLX error: dlopen of /usr/lib/dri/pvr_dri.so failed" and the display is somewhat corrupted Nov 04 15:15:44 rsalveti: is this normal or have I missed some package? Nov 04 15:15:59 alf_: the AIGLX error is expected, not the corrupted screen Nov 04 15:16:15 alf_: did you reboot? Nov 04 15:16:29 just to be sure you're loading the pvr driver and calling pvrinit Nov 04 15:16:37 then loading the xserver with the pvr driver Nov 04 15:17:58 rsalveti: actually, sorry, it is corrupted only when running a plain xinit (xterm) session. Corrupted = black but when the mouse goes over something I can see the bg normally Nov 04 15:18:26 alf_: hm, also got that sometimes, it seems that it happens when the xserver is not running at the session 0 Nov 04 15:18:39 for some reason it failed to load the first session, then it loaded the session 1 Nov 04 15:18:56 you can check by your /var/log/Xorg.*.log Nov 04 15:19:52 I remember when I got this error my driver wasn't loaded correctly, because of a kernel update that didn't recompile the pvr driver Nov 04 15:20:27 do you get any other error at the kernel and the xorg.*.log? Nov 04 15:26:03 rsalveti: no errors... gdm works normally though, so no big deal :) Nov 04 15:26:18 hm Nov 04 15:27:17 rsalveti: is that "hm"=I need more info or "hm"=ok, such is life? ;) Nov 04 15:27:50 hm=I'm interested to know why this bug happens, but have no clue currently :-) Nov 04 15:28:30 it's black but the mouse fixes the region Nov 04 15:28:38 rsalveti: yes Nov 04 15:29:07 probably because the mouse pointer is correct at the x server, but don't know why the xterm is black Nov 04 15:29:30 I remember when I got this my kernel driver wasn't loaded correctly, once I fixed that this error stopped happening Nov 04 15:30:39 in my case the driver seems to work in general eg I have gdm + desktop and es2gears runs normally Nov 04 15:31:56 hm, if you just restart gdm and load the recovery session do you also get the weird black xterm? Nov 04 15:31:59 that's interesting Nov 04 15:39:51 is there a way to get armel ppa? Nov 04 15:44:28 hrw, Best suggestion now is to wait: there was some talk at UDS about what would be required to enable them. I'm not sure of current status. Nov 04 15:45:39 Note that if it feels like you're waiting too long, porting Xen to ARM is always an available option :) Nov 04 15:55:34 rsalveti: so, it turns out that xterm in general has this problem, regardless of the session I run it in... (tried desktop, recovery, xinit) Nov 04 15:56:17 alf_: that's weird, just tested at my panda and it works fine Nov 04 15:57:52 persia: ok Nov 04 15:57:57 ;D Nov 04 15:58:31 rsalveti: gnome-terminal works fines, but urxvt exhibits the same behavior as xterm Nov 04 15:59:34 btw - does flash-kernel always require initrd? Nov 04 16:00:08 rsalveti: aha, urxvt with xft fonts works fine, the problem is with the bitmap fonts Nov 04 16:00:51 hrw: I think the default behavior is to look for an initrd Nov 04 16:01:22 alf_: interesting Nov 04 16:01:40 ko Nov 04 16:10:56 NCommander: there? Nov 04 16:11:04 NCommander: where and how is flash-kernel invoked? Nov 04 16:11:14 rsalveti: ^^ ? Nov 04 16:11:46 asac: generally when updating the kernel package Nov 04 16:12:07 i know that man ;) Nov 04 16:12:11 it'd make sense to call it also when updating the initrd, but don't know if it's doing this currently Nov 04 16:12:33 asac: so, what do you need to know exactly? :-) Nov 04 16:12:38 where and how ;) Nov 04 16:12:41 not when ;) Nov 04 16:12:54 trigger, hardcoded postinst of kernel etc. Nov 04 16:12:59 and if trigger, where is it ;) Nov 04 16:18:12 asac: flash-kernel has a hook at /usr/share/initramfs-tools/hooks/flash_kernel_set_root Nov 04 16:18:29 now need to check if the kernel also calls it directly Nov 04 16:19:13 rsalveti: that one doesnt call flash-kernel though ;) Nov 04 16:19:16 /usr/share/initramfs-tools/hooks/flash_kernel_set_root that is Nov 04 16:20:04 true Nov 04 16:20:44 argh, the kernel has lots of perl-scripts all around Nov 04 16:20:51 it's setting the bootloader as flash-kernel Nov 04 16:20:57 but need to trace how it's using it Nov 04 16:21:42 rsalveti: where is it setting that? Nov 04 16:22:20 on the master tree: debian.master/control.d/vars.omap Nov 04 16:22:23 the same for omap 4 Nov 04 16:23:01 but still don't know how it's using it, looking at the code atm Nov 04 16:25:03 seems to be related only with dependency Nov 04 16:28:05 hmm.. flash-kernel looks ugly Nov 04 16:28:11 lot of code duplication Nov 04 16:28:51 hrw: heheh, it is Nov 04 16:29:07 I dont think it was really intended to grow from a simple script Nov 04 16:29:24 that's why we have some other blueprints that NCommander added to improve the arch detection Nov 04 16:29:24 generate_uImage(TMPMOUNT/uImage,/boot/uImage,0x80008080,0x80008080) is what most devices needs Nov 04 16:29:47 instead each machine has similar code to call mkimage, do backup of old kernel etc Nov 04 16:30:06 * hrw adds efikamx smartbook support Nov 04 16:31:30 which is fun as I do not use initrd on it Nov 04 16:35:42 hrw: do you know how much SPI-NOR flash there is the the smartbooks Nov 04 16:36:08 Last time I saw a number it was 4MiB, which isn't enough for an initrd, but there's the option of booting via microSD / MMC/SD instead Nov 04 16:37:11 dmart: kernel has pata driver builtin so building from internal "ssd" is fine without initrd Nov 04 16:37:23 dmart: and by default kernel/initrd are read from pata drive Nov 04 16:37:39 dmart: if sd/mmc is in slot then boot.scr is read from there Nov 04 16:37:45 handy to test kernels Nov 04 16:42:43 hrw: ah, right. SSD didn't used to be supported (the model I had didn't have any SSD) Nov 04 16:45:53 asac: update-initramfs calls flash-kernel Nov 04 16:46:13 asac: http://paste.ubuntu.com/525757/ Nov 04 16:46:19 rsalveti: ack;) Nov 04 16:58:34 bug 671027 added Nov 04 16:58:35 Launchpad bug 671027 in flash-kernel (Ubuntu) "Add Efika MX Smartbook/Smarttop support (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/671027 Nov 04 17:03:39 rsalveti ? Nov 04 17:03:55 mpoirier: ? ? Nov 04 17:04:42 Rodrigo, Kubuntu fellow, told me you tried to get the kernel going on the n900 but things werent' working properly. Nov 04 17:04:48 is this correct ? Nov 04 17:19:04 mpoirier: I got a working kernel, but didn't have time to check if everything was working Nov 04 17:20:02 got maverick booting, but then didn't have time to continue the work Nov 04 17:20:16 mpoirier: do you have a n900 around? Nov 04 17:20:35 I basically used the u-boot solution to boot the kernel and rootfs from the external sd card Nov 04 17:20:42 rsalveti: I don't - Scott Kitterman is supposed to have dropped one in the mail for me... Nov 04 17:21:00 yes indeed, that is a good solution. Nov 04 17:21:24 there seems to be good support already - there may not be too much to do... Nov 04 17:21:32 did X came up ? Nov 04 17:21:42 mpoirier: cool, I basically added the n900 meego patches on top of the maverick branch Nov 04 17:21:50 mpoirier: yep, was able to login at the gdm and etc Nov 04 17:22:23 ah ! so you did all the hard work. Nov 04 17:22:36 but the touchscreen didn't work well, the axis was inverted Nov 04 17:22:54 let me check if I pushed the latest stuff from my branch Nov 04 17:23:52 humm... Could be userspace space thing or wrong assumption in kernel land. Nov 04 17:23:58 axis can be changed in kernel Nov 04 17:24:00 yup Nov 04 17:24:11 it is common problem :D Nov 04 17:24:16 hrw: indeed. Nov 04 17:34:55 mpoirier: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/rsalveti-master-n900 Nov 04 17:35:10 mpoirier, You may also be looking for rbelem :) Nov 04 17:35:15 still need some love, and need to sync the config with the meego one Nov 04 17:35:48 rbelem, that's the IRC i was looking for... Nov 04 17:36:56 rsalveti: thanks Nov 04 17:38:43 bye Nov 04 18:00:35 hey, mpoirier Nov 04 18:00:38 :-) Nov 04 18:01:38 rbelem: hold on... Nov 04 18:01:48 rbelem: I'll get back to youi. Nov 04 18:02:01 mpoirier, oki Nov 04 20:01:56 asac: I'm herenow What do you mean on when its called? Nov 04 20:05:18 NCommander: all sorted ;) Nov 04 20:05:36 NCommander: just needed someone with other perspective to find where flash-kernel gets invoked ;) Nov 04 20:06:19 asac, If you want to not invoke it for a specific environment, please add a stanza making it no-op, rather than killing the call. Nov 04 20:08:08 persia: that was not the context ;) Nov 04 20:08:18 * asac wonders why everyone thinks i always want to kill something :-P Nov 04 20:09:08 * persia has hardware on which running flash-kernel is useless and annoying, and presumes everyone else has exactly the same wants and needs Nov 04 20:11:10 persia: thats cause iMX51 hardware doesn't change /proc/cpuinfo Nov 04 20:12:24 NCommander, At least all my i.MX51 hardware has distinguishable /proc/cpuinfo: but not all of it boots kernels from NAND. Nov 04 20:13:32 So, if someone adds working in-archive kernels for my hardware, I'll put two different stanzas in flash-kernel to do different things. Nov 04 20:13:39 (one of which would be no-op) Nov 04 20:17:47 persia: distishable in what way? Nov 04 20:19:04 Processor, CPU revision, Hardware, and Revision all differ. I'll probably use Hardware in flash-kernel Nov 04 20:20:11 Actually, maybe I'll just do that today, in advance of there being a working kernel, as long as I'm thinking about it (already had /proc/cpuinfo up for comparison for other reasons) Nov 04 20:21:46 Only tricky bit being that NAND partitions are a bit of a joke, and there's no way to safely probe them. Following the convention of maintaining manufacturer bootloader defaults is probably most polite, but not likely long-term best. Nov 04 20:22:11 (but that affects every flash-kernel stanza, so ...) **** ENDING LOGGING AT Fri Nov 05 02:59:58 2010