[03:02] if i put the new kernel uImage-2.6.34 in the boot directory and extract the kernel modules to the root fs, will that successfully update the kernel? [03:03] ..and try to reboot? [03:04] or is there docs on how to upgrade the kernel on a sheevaplug? [08:30] lag: Hi! I just look at the syslink patch applied by Tim, and I don't see the modalias, nor the module_init(). Did you test this patch? I do not expect it to be functional... [08:31] What do you mean you don't see them? [08:34] Sebjan? [08:34] lag: in the patch applied on the top of the tree, there is not the MODULE_ALIAS code for example [08:35] * lag looks [08:35] sebjan: that's true, please follow the email thread started from lag [08:36] lag: in you v1 patch, there is MODULE_ALIAS code [08:37] lag: but in the v2 patch which is in Maverick now, there is no such code [08:37] lag: i guess sebjan is asking this [08:37] correct :) [08:37] lag: btw, thanks a lot for email me the blob file [08:37] cooloney, sebjan: You're correct, I'll add it as a separate patch right now [08:38] lag: great, man [08:38] lag: we also need the module_init(), right? [08:38] Why do you need that? [08:39] lag: for the omap4_syslink_init function to be called on startup? Or the __init does it? === hrw|gone is now known as hrw [08:40] morning [08:41] sebjan: The device_initcall(omap4_syslink_init); does it [08:47] sebjan: http://kernel.ubuntu.com/git?p=lag/ubuntu-maverick.git;a=shortlog;h=refs/heads/ti-omap4-syslink [08:48] Sorry about that. I did a git reset --mixed [08:48] Added omap4-common.c and must have missed off ipc_drv.c [08:49] It was still in my tree though, hence when I tested it, it worked [09:02] lag: no problems. By the way, we shall stick with syslink drivers static right now, as we are seeing issues when using them as modules. We are investigating that, and will send an update when this will be fixed (then we can activate syslink drivers as modules) [09:03] No problem - keep me posted [09:05] lag: yes, sure! [09:27] sebjan: Can you have a look at the patch on the mailing list please [09:27] sebjan: If it's okay can you ack it as well? [09:30] lag: done [09:32] sebjan: Thanking you! === fta__ is now known as fta [10:34] sebjan, i still see hangs with the recent panda kernel === amitk is now known as amitk-afk [10:41] a lot less frequent, but they happen [10:45] ogra: Must be userspace ;) [10:45] My kernel works flawlessly [10:45] :) [10:46] the archive kernel ? [10:46] installed from the package [10:49] Nope [10:50] But it will be the latest Maverick kernel won't it? [10:51] I'm in the process of flahsing my SD card with the latest archive [10:51] ok [10:52] ogra: If one thing (within the kernel) is crashing continuously, raise a bug report and I'll take a look [10:53] lag, here is another one to play with bug 603062 [10:53] Launchpad bug 603062 in linux-ti-omap4 (Ubuntu Maverick) (and 1 other project) "oops in parport_pc_probe_port function of parport_pc module (affects: 1) (heat: 8)" [Medium,New] https://launchpad.net/bugs/603062 [10:55] The new image still doesn't work with my monitor :( [10:55] And there's no console output either [10:56] the image should start in console mode by default [10:56] we dont use splash during resizing yet [10:57] I have nothing [10:57] Uncompressing Linux... done, booting the kernel. [10:57] It's been like this for 5mins [10:57] thats serial [10:57] Do you think it's resizing? [10:57] Yeah [10:57] we dont use serial on ubuntu images [10:57] And nothing on the monitor [10:57] Zero [10:57] Ziltch [10:57] Nada [10:58] do you know a cmdline that works for you ? [10:58] lag: try enabling DEBUG_LL and DEBUG_LL_CONSOLE [10:58] ukleinek: From within the kernel? [10:58] lag: make menuconfig [10:58] ukleinek, note that ubuntu images dont have console= settings by default [10:58] fdr editconfigs ;) [10:59] breaks the splash [10:59] Still nothing ... [10:59] * lag whistles [10:59] lag, lets try to find a cmdline that works for everyone [11:00] there wont happen anything, if your monitor doesnt init it wont do that later either :) [11:00] I have a cmdline that works for me [11:00] lag: add a printch(c) to emit_log_char [11:00] What will happen if I restart the board during the resizing process? [11:00] you will have to re-dd [11:00] the filesystem will be corrupted [11:00] Grrrrrrrrrrrrr [11:00] What if I wait [11:01] It will take the same amount of time [11:01] it will move on and start X to configure the system eventually [11:01] which you likely wont see if the framebuffer doesnt work [11:02] dd the image newly, mount the first partition and add your cmdline changes to boot.scr [11:02] (before booting it for the first time) [11:02] dont forget mkimage [11:03] it would be good if we can find the smallest common denominator that makes all monitors work [11:04] or if TI can fix the EDID code (preferred indeed) === fta_ is now known as fta [11:06] 1024x768 should work [11:06] well, depends on your monitor [11:06] mine cant do non widescreen modes on the HDMI port afaik [11:07] but i'll try [11:07] XGA was default beagleboard resolution [11:11] lag, what are the options you use [11:11] setenv bootargs omapdss.hdmimode=0 omapdss.hdmicode=4 vram=15M, omapfb.vram=0:5M noinitrd mem=512M root=/dev/mmcblk0p2 rootwait ro ip=none; mmcinit 0; fatload mmc 0 0x80200000 uImage; bootm 0x80200000 [11:12] omapfb.vram=0:5M ?!? [11:12] thats definately to less [11:12] TI told me to use it [11:12] Well that works [11:12] But 32 and 8 work for me also [11:13] vram=15M is also to less for our kernel [11:13] setenv bootargs omapdss.hdmimode=0 omapdss.hdmicode=4 vram=32M, omapfb.vram=0:8M noinitrd mem=512M root=/dev/mmcblk0p2 rootwait ro ip=none; mmcinit 0; fatload mmc 0 0x80200000 uImage; bootm 0x80200000 [11:13] we enable all possible output devices [11:13] can you try without omapfb.vram=0:8M ? [11:13] Well your cmdline doesn't work for me so ... [11:13] I can [11:13] * ogra will try omapdss.hdmimode=0 omapdss.hdmicode=4 on his monitor [11:14] * ogra just tried omapdss.hdmimode=0 omapdss.hdmicode=35, that makes the board crash once X is up [11:15] and cuts of 60% of the bottom of the screen on my monitor [11:17] lag, also i dont get why mem=512M would work for you [11:17] i was clearly told that will cause issues and hard locks [11:18] Probably because I'm not running a GUI [11:18] What was it again 468? [11:18] well, robclark said thats reserved ram for the coprocessor [11:18] i dont think that should harm X [11:18] or have any influence [11:18] * lag shurgs [11:18] It just does [11:18] What is the correct value? [11:19] 463> [11:19] ? [11:19] 463 [11:19] right [11:19] I'm using a kernel with TI's hack in it at the moment [11:20] sigh, the last crash trashed my SD [11:20] Let me build my own and I'll try it out [11:20] lag, that doesnt help at all [11:20] please use the same kernel we all use [11:20] ogra: I'm working with both [11:21] I have other things going on too :) [11:21] me too [11:22] So, I need to be running both kernels [11:22] but it doesnt help the images if you dotn use and improve the image kernels [11:22] Doesn't the daily builds use the latest Maverick kernel anyway? [11:22] the one in the archive [11:22] which is behind the git tree [11:23] Where is it built from? [11:23] the git tree [11:23] but its not built every day [11:24] tim builds it from kernel.ubuntu.com from cooloneys tree afaik [11:24] every few weeks [11:25] with mode=4 i get a small square in the top left corner of my monitor [11:25] i dont think any of these options will help, TI needs to fix the EDID detection code properly [11:26] its bad enough that we have to use *any* cmdline options [11:27] ogra: http://paste.ubuntu.com/460578/ [11:27] Try some more [11:27] See what works for you [11:27] well, what else works for you ? [11:27] I don't know yet [11:27] doesnt help if i try all of them [11:27] What do I have to mkimage on? [11:28] do* [11:28] the edited boot.scr [11:28] How do you do that? [11:28] I've only done uInitrd and uImage [11:28] sudo mkimage -A arm -T script -C none -n "Ubuntu boot script" -d boot.scr /boot.scr [11:28] the first boot.scr needs to be plain text (no uboot header) [11:29] thats the one you edited [11:29] I only have the one with the header on [11:29] Should I just take that off? [11:29] yeah [11:29] just delete it in vi [11:30] mkimage adds it again [11:30] vi? pfft [11:30] well, or use: strings /boot.scr >./boot.scr [11:30] but that might leave cruft at the top line [11:31] lag, can you try omapdss.hdmicode=6 ? thats one i could imagine all HDMI monitors should be able to do [11:32] err. line 6 [11:32] thats code 28 indeed [11:33] 4 sort of works [11:33] I can see it [11:33] 4 doesnt work here [11:33] But it's out of range of my monitor [11:33] And is shakey [11:33] well, it draws on the screen but is unusable [11:34] Running /scripts/local-bottom ... [11:34] 640x480n is nothing we can run the desktop in [11:34] you wont be able to reach any of the buttons in the apps [11:35] I'll try 28 when it's finished doing 'its thing' [11:35] It doesn't matter anyway - my keyboard doesn't work! [11:35] Grr [11:36] no space left on device? [11:37] It's a 16GB card? [11:37] it didnt resize [11:37] Why not? [11:37] MMC issues i guess [11:37] But it resizes yours? [11:37] GrueMaster reported similar issues with some SD cards [11:37] I did get the parport segfault though [11:37] it resizes the five i have here for testing [11:38] Do you have a 16GB SDHC card there? [11:38] GrueMaster seems to have a similar card to yours, please check with him (once he is up) if you got the same [11:38] no [11:38] my biggest one is 8G [11:38] SDHC? [11:38] yes [11:38] Odd [11:39] Can I resize it manually? [11:39] error -110? [11:39] no [11:39] Nope [11:39] Different bug [11:39] can you plug the card into your pc and check for /var/log/jasper.log please === amitk-afk is now known as amitk [11:40] it should have error messages [11:40] where exactly do you get the "no space left on device" errors btw [11:40] any particular process thats causes them ? [11:41] code 28 doesnt work here either btw [11:41] chops off the bottom half of the screen [11:44] lag, where do you get the no spaxce messages ? [11:44] On the monitor [11:44] if its udevd thats a tmpfs issue (udev writes to a tmpfs) [11:44] haha [11:45] ;) [11:45] I can't remember what it was doing now [11:45] hmm [11:45] It could have been udev [11:45] well, then only jasper.log can tell [11:45] The screen has gone now [11:45] does X start ? [11:45] Nope [11:45] the timeframe was also way to short [11:45] resizing 16G will likely take about 15min [11:46] you guys are insane with that resizing [11:46] so please get me the log so i can see what went wrong [11:46] hrw, why ? [11:46] hrw, compared to a 2-3h install its quite reasonable [11:47] ogra: cant I fetch tarball which will be unpacked to card? [11:47] plus you need an additional target device [11:47] hrw, that will be as messy as a rootstock image [11:47] you will never get a proper ubuntu install that way [11:48] it will be something "ubuntu alike" [11:48] so now I get 512MB image to dd on card which will start with initrd which will resize that 512MB to whole card? [11:49] you get a 1.4G image and yes, initrd is essential for a proper ubuntu image === fta_ is now known as fta [11:49] ogra: 28 from the cmdline is still out of range [11:49] However [11:49] When I do: echo 28 | sudo tee -a /sys/devices/platform/omapdss/display0/custom_edid_timing [11:49] It looks great [11:49] oh [11:49] hmm [11:49] why I can install x86(-64) with 1CD but arm needs >2CD? [11:50] hrw, because x86 uses a squashfs and a full installer [11:50] our image is bz2 and needs to be uncompressed before dd [11:50] and is fully preinstalled [11:50] hrw: Our boards don't have CD drives :) [11:50] well, they have SD slots [11:51] Yes, hence why we use entire images [11:51] which we used before in a similar way to CD drives [11:51] so you had to install a live image to USB from SD card [11:51] Our full install takes 5 mins. How long does X86 take? [11:51] a) the installation can take 2-3h depending on the card [11:52] b) you need to use the SD as a "boot floppy" on boards like panda [11:52] so you need to trash the installation media at the end of the install [11:52] very very ugly [11:52] Yup [11:52] x86 takes between 20 and 40min [11:52] with a speedy CD drive [11:53] it copies the 2G from the squashfs to the HDD [11:53] and then removes bits [11:54] in our images the resizing takes the longest time, after that its relatively speedy since only oem-config runs [11:54] sadly resizing takes at least 10min [11:55] lag, anything intresting in the jasper.log file ? [11:55] It was trashed [11:55] gah [11:55] I trashed it [11:55] I am re-running [11:56] what you can do is to add break=bottom on the cmdline, that will give you a busybox shell [11:56] jasper.log lives in /dev/.initramfs/jasper.log there [11:57] you can ctrl-d out of that shell and booting moves on [11:57] (works also with break=top or premount, depending where you want to inspect the initramfs) [11:57] Just tested 28 with the archive kernel [11:57] Nada [11:57] Got to reflash now :( [11:57] sad [11:58] we really need TI to fix that properly then [11:58] fiddling with cmdline options in the default install is ugly anyway [11:58] * ogra prefers to not have more than "quiet splash root=UUID=..." [11:59] and ro [12:02] Well I have direct contact with the video people at TI ... [12:02] robclark is resident here too :) [12:03] Is robclark video people? [12:03] yep [12:04] Cool - let's bother him :) [12:04] Where is he based? [12:04] tx [12:10] * ogra played with /sys/devices/platform/omapdss/display0/custom_edid_timing [12:10] sadly i have the same issue as with setting modes on cmdline [12:10] screen isnt fullscreen [12:11] i either have a small square at the top left of the monitor or the screen extends beyond monitor size [12:12] * ogra wishes DVI would just work === fta is now known as fta2 === fta2 is now known as fta [12:13] :( [12:13] hmm [12:13] DVI does work [12:14] well, the HDMI->DVI cable from my beagle does at least [12:14] weird [12:14] ogra: .initramfs doesn't exist [12:14] but same effect [12:15] /dev/.initramfs/ [12:15] init mounts it under /dev [12:15] its a tmpfs [12:16] Oh okay [12:16] I'll try dropping into a Busybox shell then [12:16] * lag is reflashing [12:16] This sucks [12:17] aha, DVI doesnt work on boot at all [12:18] well, it does, but puts the screen to weird ranges [12:20] * ogra takes a break [12:43] * lag pounces on robclark! [12:43] hi lag [12:43] Hey robclark [12:43] hi robclark [12:43] How are you this afternoon/morning? [12:43] hi hrw [12:44] * robclark is just finishing my coffee [12:44] Can you type and drink? :) [12:44] Or would you like me to wait for you to finish? [12:44] no, I can type [12:46] We're having video issues [12:46] uh-oh [12:46] I have an LG FLATRON W2261VP [12:47] I have tried omapdss.hdmicode=* [12:47] what resolution? If it could do 1920x1080 then, in theory, it shouldn't even need any bootargs.. [12:48] robclark: thats 22" so rather not fullhd [12:48] And depending on what '*' is, I either receive shakey text and the monitor say "out of range" [12:48] Or I get nothing [12:48] Yes, it does 1920x1080 [12:48] Or should do [12:49] hmm.. in the printk's from the HDMI driver you should see what resolution the driver *thinks* the monitor can do [12:49] But it doesn't [12:49] With no args, the monitor just goes to sleep [12:49] but I think the driver still has troubles with some monitors.. [12:49] We don't have access to the boot-up messages with this kernel [12:50] * lag flicks to another kernel [12:50] hmm... ok.. that is a bit inconvenient [12:50] It does the same thing on my kernel [12:50] although to be honest, I'm not a display driver guy.. [12:51] if you could get a log of the boot msgs, we send that to me (rob@ti.com) and I'll loop in display driver team [12:51] * robclark thinks what is really needed is to get the display driver team access to more monitors to test with [12:51] I am in direct contact with Mythri [12:51] ok, perfect [12:52] But things are slooooooooow over email [12:52] she knows the HDMI driver more than I.. [12:52] ok.. I'll try to pester them to get on IRC.. [12:53] That could be a good thing [12:53] I think she's in the far east though isn't she? [12:53] yes [12:53] And would have gone home by now? [12:53] lag, afaik, the trouble with higher resolutions is that the driver can't keep up the refresh rate [12:53] well, most of them work rather late.. so probably still in the office now [12:54] it's pretty much up to the monitor whether it will still work at that point === fta_ is now known as fta [12:54] cwillu_at_work: So where do we go with this? [12:55] lag, working from memory here, having spoken to folks before on this. [12:55] hang on a sec, let me check my logs [12:55] The odd thing is, a mode that doesn't work on the cmdline using omapdss.hdmicode will work using: echo * | sudo tee -a /sys/devices/platform/omapdss/display0/custom_edid_timing [12:56] And it will work perfectly then? [12:56] oh, really? [12:56] Yeah! What gives? [12:56] But that's no good for be, as I'm working on boot-up code [12:57] what does .hdmicode= do that a normal omapdss command line doesn't? [12:57] me* [12:57] That's what I'm looking for now [12:57] ;) [12:57] * lag is on it [12:57] omapfb.mode=dvi:1024x768MR-16 [12:57] is what I'm usually doing [12:57] although usually 1280x1024 or 1600x900 [12:57] I'm using hdmi [12:58] cwillu_at_work: on beagleboard? [12:58] same thing [12:58] yes [12:58] oh, are we not talking beagles? [12:58] Nope [12:58] cwillu_at_work: they talk about pandaboard [12:58] I have Beagle working [12:58] I'd still imagine it's the same thing though [12:58] cwillu_at_work: panda can do fullhd-60 [12:58] just :1280x1024MR-16 instead of DVI: [12:59] especially if it works echoing to the sysfs [13:00] I might be out on the road with my boss today, I'll find out in an hour. If not, I'm interested in spelunking into the relevant dss code today :)\ [13:04] cwillu_at_work: I just tried your args - the monitor just stuck its fingers up at me and went to sleep [13:04] does it report the refresh rate it's getting before it goes to sleep? [13:05] and did you try any other options re: the dvi: bit? [13:05] Yes [13:06] dvi and hdmi [13:06] Just did this: echo 40 | sudo tee -a /sys/devices/platform/omapdss/display0/custom_edid_timing [13:06] And it appeared [13:06] Looking perfect [13:06] Grrrrrrrrrrr [13:06] lag, hmm, so setting it via bootargs seems broken? [13:07] Correct [13:08] 'TI: please fix your drivers' [13:08] :) [13:14] btw, for those who haven't already noticed: #pandaboard [13:14] lag: http://marcin.juszkiewicz.com.pl/2009/06/12/ti-please-fix-your-usb/ [13:14] Does anyone have a keyboard and mouse attached to their Panda? [13:15] lag: yup [13:15] lag, come to think of it, there should be another file in that folder with the names for each display [13:15] try doing a "cat *", and see if anything shows up [13:15] hrw: How funny! [13:15] * robclark has to run.. be back later === robclark is now known as robclark|away [13:16] EDID-Informationcat: driver: Is a directory [13:16] 1 [13:16] cat: hpd_enabled: Input/output error [13:16] cat: mirror: No such file or directory [13:17] hdmi [13:17] cat: rotate: No such file or directory [13:17] cat: subsystem: Is a directory [13:17] 0 [13:17] 148500,1920/88/148/44,1080/4/36/5 [13:17] DRIVER=hdmi_panel [13:17] 1 [13:17] cat: wss: No such file or directory [13:17] Whoops [13:18] so, my suspicion is that hdmi or hdmi_panel is the right invocation then [13:18]