| topfs2 | I keep getting these on pandaboard with ubuntu maverick | 01:16 |
|---|---|---|
| topfs2 | dpkg: error processing initramfs-tools (--configure): | 01:16 |
| topfs2 | subprocess installed post-installation script returned error exit status 1 | 01:16 |
| topfs2 | Is it known or have I done something stupid? :) | 01:16 |
| === asac_ is now known as asac | ||
| === amitk is now known as amitk-afk | ||
| === amitk-afk is now known as amitk | ||
| === hrw|gone is now known as hrw | ||
| hrw | moin | 08:37 |
| playya__ | moin | 08:40 |
| sebjan_ | rsalveti: yes, will do the test. Thanks for reminding me! | 08:42 |
| hrw | rsalveti: found issue. natty initrd was wrong - replaced with maverick one and got it booted | 09:24 |
| hrw | total used free shared buffers cached | 09:24 |
| hrw | Mem: 993492 120172 873320 0 18744 62900 | 09:24 |
| === XorA|gone is now known as XorA | ||
| === kmargar is now known as markos_ | ||
| rsalveti | hrw: cool, I don't think natty is tested already | 11:11 |
| hrw | yep | 11:15 |
| rcn-ee | hrw, saw the same thing on my beagles, something's wrong with natty's unitrd generation... | 11:23 |
| hrw | thx | 11:26 |
| === dmart_ is now known as dmart | ||
| repete | Hi all | 11:56 |
| repete | Does OpenOffice.org work on Ubuntu 10.04 for ARM? | 11:57 |
| repete | or 10.10 for that matter... | 11:57 |
| dmart | don't have it in front of me right now, but I believe it works fine | 11:58 |
| repete | dmart: thx | 11:59 |
| === amitk is now known as amitk-afk | ||
| alf_ | 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? | 12:10 |
| rsalveti | alf_: hm, did you try the blaze files? | 12:10 |
| rsalveti | alf_: https://wiki.ubuntu.com/ARM/OMAPMaverickInstall | 12:10 |
| alf_ | rsalveti: Yes. I copied them to the boot partition. I also added console=/dev/ttyO2... I have console output but no login. | 12:11 |
| rsalveti | 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 | 12:11 |
| rsalveti | 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 | 12:12 |
| rsalveti | then upstart will call the proper getty | 12:12 |
| alf_ | rsalveti: ok, I will try that. Thanks! | 12:13 |
| rsalveti | but seems weird that you don't have any mouse and keyboard | 12:13 |
| rsalveti | alf_: http://paste.ubuntu.com/525611/ | 12:13 |
| rsalveti | ndec1: vstehle: do you know any hw difference that would make the omap 4 sdp board behave differently than blaze? | 12:22 |
| rsalveti | alf_ currently got an sdp to work with, and I never saw anyone using and booting with current sw | 12:22 |
| vstehle | rsalveti, I wonder if alf_ is using an ES2.x to begin with... | 12:37 |
| rsalveti | vstehle: hm, true | 12:37 |
| vstehle | 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. | 12:39 |
| alf_ | vstehle: thanks. How can I tell if I have ES2.x? | 12:41 |
| rsalveti | alf_: do you have "OMAP4430 ES2.0" at your dmesg? | 12:48 |
| rsalveti | 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 | 12:48 |
| alf_ | rsalveti: yes I do have "OMAP4430 ES2.0" | 12:49 |
| alf_ | rsalveti: and now I have a login :) | 12:49 |
| rsalveti | 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 | 12:52 |
| alf_ | rsalveti: I also see an ES2 GP sticker on a chip | 12:53 |
| rsalveti | that's better :-) | 12:53 |
| alf_ | rsalveti: vstehle: ndec1: for anyone who is interested my dmesg output is http://paste.ubuntu.com/525642/ | 12:55 |
| alf_ | when I plug in a usb device nothing happens :( (eg no dmesg output) | 12:55 |
| alf_ | I have tried all 3 usb ports (hi-speed, full-speed, OTG) | 12:56 |
| sveinse | Anyone with experience with PulseAudio on OMAP3? | 12:57 |
| sveinse | I am considering using PA vs. ALSA for an application (generating 8channels of 24-bit@48kHz) | 12:57 |
| rsalveti | alf_: hm, you should have at least touchscreen and keyboard working | 12:58 |
| rsalveti | don't know about usb, don't know if it worked on blaze | 12:58 |
| rsalveti | I don't think the smsc chip available at panda is also integrated at the sdp | 12:59 |
| alf_ | 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 | 12:59 |
| rsalveti | haha :-) | 12:59 |
| === xfaf is now known as zul | ||
| rsalveti | alf_: touch screen and keyboard can at least help you finishing the pre-installed image boot | 13:03 |
| rsalveti | now for usb maybe vstehle knows better | 13:04 |
| alf_ | 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 | 13:06 |
| rsalveti | hm, ok | 13:06 |
| alf_ | rsalveti: in any case, I am pretty happy having console and ssh access (hopefully) for now | 13:07 |
| vstehle | rsalveti, If I recall correctly, the USB on SDP will be in "slave" mode. Not what alf_ wants to connect a mouse. | 13:18 |
| vstehle | Alternatively, synergy2 may help here :) | 13:18 |
| vstehle | Log through UART, connect to network, install synergy, finish installer with PC keyboard and mouse. | 13:19 |
| alf_ | vstehle: interesting, I 'll give that a try later :) | 13:21 |
| rsalveti | vstehle: got it | 13:21 |
| rsalveti | yeah, over network can help :-) | 13:21 |
| === kmargar is now known as markos_ | ||
| === zyga is now known as zyga-coffee | ||
| === zyga-coffee is now known as zyga | ||
| alf_ | 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 | 15:10 |
| alf_ | rsalveti: is this normal or have I missed some package? | 15:10 |
| rsalveti | alf_: the AIGLX error is expected, not the corrupted screen | 15:10 |
| rsalveti | alf_: did you reboot? | 15:11 |
| rsalveti | just to be sure you're loading the pvr driver and calling pvrinit | 15:11 |
| rsalveti | then loading the xserver with the pvr driver | 15:11 |
| alf_ | 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 | 15:12 |
| rsalveti | alf_: hm, also got that sometimes, it seems that it happens when the xserver is not running at the session 0 | 15:13 |
| rsalveti | for some reason it failed to load the first session, then it loaded the session 1 | 15:13 |
| rsalveti | you can check by your /var/log/Xorg.*.log | 15:13 |
| rsalveti | 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 | 15:14 |
| rsalveti | do you get any other error at the kernel and the xorg.*.log? | 15:15 |
| alf_ | rsalveti: no errors... gdm works normally though, so no big deal :) | 15:20 |
| rsalveti | hm | 15:21 |
| alf_ | rsalveti: is that "hm"=I need more info or "hm"=ok, such is life? ;) | 15:22 |
| rsalveti | hm=I'm interested to know why this bug happens, but have no clue currently :-) | 15:22 |
| rsalveti | it's black but the mouse fixes the region | 15:23 |
| alf_ | rsalveti: yes | 15:23 |
| rsalveti | probably because the mouse pointer is correct at the x server, but don't know why the xterm is black | 15:24 |
| rsalveti | I remember when I got this my kernel driver wasn't loaded correctly, once I fixed that this error stopped happening | 15:24 |
| alf_ | in my case the driver seems to work in general eg I have gdm + desktop and es2gears runs normally | 15:25 |
| rsalveti | hm, if you just restart gdm and load the recovery session do you also get the weird black xterm? | 15:26 |
| rsalveti | that's interesting | 15:26 |
| hrw | is there a way to get armel ppa? | 15:34 |
| persia | 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. | 15:39 |
| persia | Note that if it feels like you're waiting too long, porting Xen to ARM is always an available option :) | 15:40 |
| alf_ | rsalveti: so, it turns out that xterm in general has this problem, regardless of the session I run it in... (tried desktop, recovery, xinit) | 15:50 |
| rsalveti | alf_: that's weird, just tested at my panda and it works fine | 15:51 |
| hrw | persia: ok | 15:52 |
| hrw | ;D | 15:52 |
| alf_ | rsalveti: gnome-terminal works fines, but urxvt exhibits the same behavior as xterm | 15:53 |
| hrw | btw - does flash-kernel always require initrd? | 15:54 |
| alf_ | rsalveti: aha, urxvt with xft fonts works fine, the problem is with the bitmap fonts | 15:55 |
| rsalveti | hrw: I think the default behavior is to look for an initrd | 15:55 |
| rsalveti | alf_: interesting | 15:56 |
| hrw | ko | 15:56 |
| asac | NCommander: there? | 16:05 |
| asac | NCommander: where and how is flash-kernel invoked? | 16:05 |
| asac | rsalveti: ^^ ? | 16:06 |
| rsalveti | asac: generally when updating the kernel package | 16:06 |
| asac | i know that man ;) | 16:07 |
| rsalveti | it'd make sense to call it also when updating the initrd, but don't know if it's doing this currently | 16:07 |
| rsalveti | asac: so, what do you need to know exactly? :-) | 16:07 |
| asac | where and how ;) | 16:07 |
| asac | not when ;) | 16:07 |
| asac | trigger, hardcoded postinst of kernel etc. | 16:07 |
| asac | and if trigger, where is it ;) | 16:07 |
| rsalveti | asac: flash-kernel has a hook at /usr/share/initramfs-tools/hooks/flash_kernel_set_root | 16:13 |
| rsalveti | now need to check if the kernel also calls it directly | 16:13 |
| asac | rsalveti: that one doesnt call flash-kernel though ;) | 16:14 |
| asac | /usr/share/initramfs-tools/hooks/flash_kernel_set_root that is | 16:14 |
| rsalveti | true | 16:14 |
| rsalveti | argh, the kernel has lots of perl-scripts all around | 16:15 |
| rsalveti | it's setting the bootloader as flash-kernel | 16:15 |
| rsalveti | but need to trace how it's using it | 16:15 |
| asac | rsalveti: where is it setting that? | 16:16 |
| rsalveti | on the master tree: debian.master/control.d/vars.omap | 16:17 |
| rsalveti | the same for omap 4 | 16:17 |
| rsalveti | but still don't know how it's using it, looking at the code atm | 16:17 |
| rsalveti | seems to be related only with dependency | 16:19 |
| hrw | hmm.. flash-kernel looks ugly | 16:22 |
| hrw | lot of code duplication | 16:23 |
| rsalveti | hrw: heheh, it is | 16:23 |
| suihkulokki | I dont think it was really intended to grow from a simple script | 16:24 |
| rsalveti | that's why we have some other blueprints that NCommander added to improve the arch detection | 16:24 |
| hrw | generate_uImage(TMPMOUNT/uImage,/boot/uImage,0x80008080,0x80008080) is what most devices needs | 16:24 |
| hrw | instead each machine has similar code to call mkimage, do backup of old kernel etc | 16:24 |
| * hrw adds efikamx smartbook support | 16:24 | |
| hrw | which is fun as I do not use initrd on it | 16:26 |
| dmart | hrw: do you know how much SPI-NOR flash there is the the smartbooks | 16:30 |
| dmart | 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 | 16:31 |
| hrw | dmart: kernel has pata driver builtin so building from internal "ssd" is fine without initrd | 16:32 |
| hrw | dmart: and by default kernel/initrd are read from pata drive | 16:32 |
| hrw | dmart: if sd/mmc is in slot then boot.scr is read from there | 16:32 |
| hrw | handy to test kernels | 16:32 |
| dmart | hrw: ah, right. SSD didn't used to be supported (the model I had didn't have any SSD) | 16:37 |
| rsalveti | asac: update-initramfs calls flash-kernel | 16:40 |
| rsalveti | asac: http://paste.ubuntu.com/525757/ | 16:41 |
| asac | rsalveti: ack;) | 16:41 |
| hrw | bug 671027 added | 16:53 |
| ubot2 | Launchpad bug 671027 in flash-kernel (Ubuntu) "Add Efika MX Smartbook/Smarttop support (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/671027 | 16:53 |
| mpoirier | rsalveti ? | 16:58 |
| rsalveti | mpoirier: ? ? | 16:58 |
| mpoirier | Rodrigo, Kubuntu fellow, told me you tried to get the kernel going on the n900 but things werent' working properly. | 16:59 |
| mpoirier | is this correct ? | 16:59 |
| rsalveti | mpoirier: I got a working kernel, but didn't have time to check if everything was working | 17:13 |
| rsalveti | got maverick booting, but then didn't have time to continue the work | 17:14 |
| rsalveti | mpoirier: do you have a n900 around? | 17:15 |
| rsalveti | I basically used the u-boot solution to boot the kernel and rootfs from the external sd card | 17:15 |
| mpoirier | rsalveti: I don't - Scott Kitterman is supposed to have dropped one in the mail for me... | 17:15 |
| mpoirier | yes indeed, that is a good solution. | 17:15 |
| mpoirier | there seems to be good support already - there may not be too much to do... | 17:16 |
| mpoirier | did X came up ? | 17:16 |
| rsalveti | mpoirier: cool, I basically added the n900 meego patches on top of the maverick branch | 17:16 |
| rsalveti | mpoirier: yep, was able to login at the gdm and etc | 17:16 |
| mpoirier | ah ! so you did all the hard work. | 17:17 |
| rsalveti | but the touchscreen didn't work well, the axis was inverted | 17:17 |
| rsalveti | let me check if I pushed the latest stuff from my branch | 17:17 |
| mpoirier | humm... Could be userspace space thing or wrong assumption in kernel land. | 17:18 |
| hrw | axis can be changed in kernel | 17:18 |
| rsalveti | yup | 17:18 |
| hrw | it is common problem :D | 17:19 |
| mpoirier | hrw: indeed. | 17:19 |
| === zyga is now known as zyga-nc10 | ||
| rsalveti | mpoirier: http://kernel.ubuntu.com/git?p=rsalveti/ubuntu-maverick.git;a=shortlog;h=refs/heads/rsalveti-master-n900 | 17:29 |
| persia | mpoirier, You may also be looking for rbelem :) | 17:30 |
| rsalveti | still need some love, and need to sync the config with the meego one | 17:30 |
| mpoirier | rbelem, that's the IRC i was looking for... | 17:30 |
| mpoirier | rsalveti: thanks | 17:31 |
| hrw | bye | 17:33 |
| === hrw is now known as hrw|gone | ||
| rbelem | hey, mpoirier | 17:55 |
| rbelem | :-) | 17:55 |
| mpoirier | rbelem: hold on... | 17:56 |
| mpoirier | rbelem: I'll get back to youi. | 17:56 |
| rbelem | mpoirier, oki | 17:56 |
| NCommander | asac: I'm herenow What do you mean on when its called? | 19:56 |
| asac | NCommander: all sorted ;) | 20:00 |
| asac | NCommander: just needed someone with other perspective to find where flash-kernel gets invoked ;) | 20:00 |
| persia | 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. | 20:01 |
| asac | persia: that was not the context ;) | 20:03 |
| * asac wonders why everyone thinks i always want to kill something :-P | 20:03 | |
| * persia has hardware on which running flash-kernel is useless and annoying, and presumes everyone else has exactly the same wants and needs | 20:04 | |
| NCommander | persia: thats cause iMX51 hardware doesn't change /proc/cpuinfo | 20:06 |
| persia | NCommander, At least all my i.MX51 hardware has distinguishable /proc/cpuinfo: but not all of it boots kernels from NAND. | 20:07 |
| persia | So, if someone adds working in-archive kernels for my hardware, I'll put two different stanzas in flash-kernel to do different things. | 20:08 |
| persia | (one of which would be no-op) | 20:08 |
| NCommander | persia: distishable in what way? | 20:12 |
| persia | Processor, CPU revision, Hardware, and Revision all differ. I'll probably use Hardware in flash-kernel | 20:13 |
| persia | 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) | 20:15 |
| persia | 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. | 20:16 |
| persia | (but that affects every flash-kernel stanza, so ...) | 20:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!