/srv/irclogs.ubuntu.com/2009/10/06/#ubuntu-arm.txt

=== bjf is now known as bjf-afk
superdugwhy am I so impressed with linux on a processor that can run linux?04:57
ogralool, so about imx-libs and xserver-xorg-video-imx and theior linking .... xserver-xorg-video-imx needs to link against mxcfb.h/ipu.h as well (looking for it on include/linux), do you know if the policy allows it that i would copy both headers during package build into imx-libs so it would ship these two in /usr/include/linux and the xserver wouldnt have to be hacked up for isung linux-headers ?09:40
ogras/isung/using/09:42
loologra: I think this would create another libdrm and I dont think we want that; it sounds like these headers should be in the kernel tree instead?09:48
loologra: In which case we'd have to build-dep on linux-headers-imx51 instead of linux-libc-dev because of the mx51 stuff not being upstream09:49
ogralool, yes, it is in the kernel tree atm09:49
ograand imx-libs dep on linux-headers-imx51 and build fine with it09:50
ograthe xserver has no configure option to add additional includes though09:50
ograand hasnt /usr/src/linux* in its default include path09:50
ogragiven that apps that build against imx-libs always need to have the headers from linux-headers it would be more easy to have imx-libs ship them in the default include path instead of having to hack up each app that uses them09:51
loolOh right09:53
loologra: I disagree that we want imx-libs to ship them09:53
loolThese headers are in the kernel source and should remain there09:53
loologra: But we might have to move them to the expected place09:54
ograok, then i'll need to hack up the xserver autofoo09:54
loolOr add -I flags when using imx-libs09:54
loologra: Well you could also copy them in linux-fsl-imx5109:54
loolBut you'd have to be really careful in only adding new headers09:54
ograhmm, would linking not work ?09:55
loolPerhaps it's best to add an -I flag for now; until the headers make it to linux-libc-dev09:55
loolTo avoid any clash09:55
loologra: Well linking or copying, yeah, but the issue is that if the upstream kernel or another vendor or another kernel tree (e.g. lange) wants to provide the same filenames, we're in trouble09:55
loolWhile adding the -I is safe09:55
ograi could make a link from /usr/include/linux/mxcfb.h to /usr/src/linux-headers/*.../mxcfb.h in the libimx-dev package09:56
ograi think currently its highly inlikely that we get the same files anywhere09:56
ograipu.h and mxcfb.h are pretty exclusively only on the imx51 arch09:57
loolI'm not too hot on it09:57
ograwell, ok, i'll hack up the xserver for now to look in the linux-headers dir too09:58
ograbut that makes two packages that have to stay in sync09:58
loologra: Actually one thing which strikes me is that the headers are under an ABI path09:59
ograright09:59
ograwhich is pointless unless the patches get actually updated09:59
ograeven if we have an ABI bump they usually stay untouched10:00
loologra: The core of the issue is that we currently rely on linux-libc-dev/armel to build everything on armel10:00
loolWhile we truly have multiple kernel ABIs10:00
loolOne per subarch10:00
ograyeah10:00
ograplus vendor patches10:00
loolWe cant have multiple linux-libc-dev10:00
loolI think using the upstream kernel ABI/API is best for us by defalut10:00
loolBut we could use a more specific ABI/API for packages which need it, like here10:01
ograright, but that wont work for such device specific headers10:01
loolStill, this should be offered by the linux-fsl-imx51 packages10:01
ograwell, i fear any changes in the packaging of linux-fsl-imx5110:01
loolSo perhaps we should have a linux-libc-dev-fsl-imx51 which would install in /usr/include/fsl-imx51/* (/linux etc.)10:02
ograespecially this late in the cycle and with the experience i made this round10:02
lool(I'm speaking long term)10:02
loolI dont think that's doable for karmic10:02
ograyes, i understand10:02
ograright10:02
lool(But I want to get the logic right as to solve this properly next cycle)10:02
ograyup10:02
loologra: So either imx51 gets merged upstream in the kernel and we use linux-libc-dev (unlikely before long), or we come up with such a hack10:03
ograwell, atm there are in max 5 devices10:03
loologra: I'd rather use a new binary package for this since the linux-headers packages already have use cases10:03
ograso that package would be fairly empty10:03
ograwe only use three of the 5 atm10:03
loologra: I think it would be a full replacement for libc-dev10:03
loologra: In theory, the ABI could be difference in some places than the upstream one10:04
ograthough sahara was enabled in the config, i will probably switch it back on in imx-libs10:04
loologra: e.g. they could add some fb ABI calls10:04
lool(ioctls)10:04
ograah10:04
ograyep, i understand10:04
loologra: Is this approach fine with you for karmic+1?10:04
* ogra thought of it as addon package10:04
ograyup10:04
loologra: Ok; now looking at what we can do in karmic10:05
ograbloats the archive with duplkicates though ... but surely the best path to take10:05
loologra: So I dont think we want to change kernel at this point10:05
ograwell, both packages arent even in the archive10:05
ograand unlikely to enter10:05
ograso let me add hacks to the packages for now10:06
loologra: What we could do is have imx-libs build-dep on linux-headers-fsl-imx51 and copy the latest headers from there into imx-libs10:06
loolor use them directly there10:06
ograthats what i asked initially for :)10:06
ograit alreayd build-deps on the headers10:06
loolWell I prefer planning the clean fix first, then looking at immediate workarounds10:06
loologra: Do you that in imx-libs or xorg-imx51 or both?10:06
ograand libimx-dev can easily copy them into /usr10:07
ograi would do it in libimx-dev and make it ship them in /usr/include/linux10:07
ograthen have the xserver just b-d on libimx-dev10:07
loolWell dont you think we can implement the /usr/include/fsl-imx51 part directly?10:07
ograthat would mean to hack up the xserver package to look in there10:08
loolWhich will be needed for the long term plan anyway10:08
ograok10:08
ograso i'll do both10:08
ogracopy the headers and hack up xserver10:08
loolCool10:09
ograthanks :)10:09
loologra: Do you want to file the bug for the lucid stuff?10:09
ogracan do10:09
loolOk10:09
loologra: I just had this bug again that I did a reboot on babbage 2.0 and it shutdown instead; do you know if we have a bug for that or shall I file one?10:09
ograwe dont10:09
ograand i didnt see such behavior yet10:10
loologra: So reboot works for you?10:10
ograyep10:10
ograbut thats 2.510:10
JamieBennettlool: I had the exact same thing yesterday10:10
loolRight10:10
ograyou have other weird issues on your 2.010:10
loolJamieBennett: On 2.0 and/or 2.5?10:10
JamieBennett2.010:10
* ogra remembers the xterm issue 10:10
loolJamieBennett: did you try on 2.5?10:10
JamieBennettI don't have the lead yet (going to a specialist shop this morning to get it.10:11
JamieBennett)10:11
loolb44438610:13
lool#44438610:13
ograwe should try to make that bug appear on 2.5 too, then it would at least shut off at all :P10:14
loolEh10:15
=== Stskeepz is now known as Stskeeps
loolI thought the same, that it was really ironic that one shuts off too easily while the other cant10:15
ograyeah :)10:15
JamieBennettlool: have you seen video issues with 2.0 on the desktop? I have about 20 pixels missing from the top left hand corner running horizontal.10:15
ogracould that be caused by the toolchain issue ?10:15
loologra: make sure you include karmic+1 or something in the headers bug10:15
ograwill do10:16
loologra: No10:16
loolThe toolchain issues are only problematic when doing stack unwinding in C++ stuff, so not in the kernel10:16
ograok10:16
loolJamieBennett: I did file a couple of video bugs on b2.010:16
* JamieBennett goes to look10:16
loolJamieBennett: 2.5 is more stable so nobody bothers with the 2.0 specific bugs10:16
JamieBennettok10:17
ograJamieBennett, does it go away if you definate a video= option on the cmdline10:17
loolJamieBennett: https://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51 and ~ubuntu-armel bugs are good places to check for them10:17
* ogra thinks he has seen that before 10:17
loolhttps://bugs.launchpad.net/ubuntu/+source/linux-fsl-imx51/+bug/43096910:17
ubot4Launchpad bug 430969 in linux-fsl-imx51 "Display unstable when running xterm" [Low,New]10:17
ograJamieBennett, make sure to have the laters redboot-tools (0.7) you can easily edit the cmdline with redboot-cmdline from the running system10:18
JamieBennettogra: haven't tried, just strange that its 1px x 20px top left and nothing else10:18
loolhttps://bugs.launchpad.net/ubuntu/+source/linux/+bug/35895610:18
ubot4Launchpad bug 358956 in linux-fsl-imx51 "armel Babbage iMX51 line truncation and addition on VGA output" [Undecided,Incomplete]10:18
ograi think it goes away if the driver gets a video= option10:18
JamieBennettok10:18
loolJamieBennett: Can you reopen that last bug if it matches?10:19
JamieBennettlool: Will do.10:19
ograJamieBennett, try with video=mxcfb:1024x768-32@6010:21
JamieBennettogra: OK10:21
* ogra hopes he has that right from the top of his head10:21
=== doko__ is now known as doko
loolJamieBennett: also, the first bug (xterm makes display unstable) wasn't confirmed by anyone else; it's low prio but your confirmation would be nice10:56
JamieBennettlool: I'll look into it now10:59
ogralool, the truncation bug is different though ... its just a small square above thats rendered black directly over the applications menu11:06
ogras/above/at the top/11:06
loolJamieBennett: Or perhaps file a new bug, use your judgement11:26
loolIt was painful to setup this local debmirror, but it feels so snappy when I use it that I really don't regret it!11:27
loolI think I'll enjoy deboostrap as well11:27
JamieBennettJust caught your Bug #430969 on camera lool :)12:09
ubot4Launchpad bug 430969 in linux-fsl-imx51 "Display unstable when running xterm" [Low,New] https://launchpad.net/bugs/43096912:09
loolk12:36
ograogra@babbage2:~/devel/kernel/linux-fsl-imx51-2.6.31$ grep -r "pin config changed" *12:38
ograogra@babbage2:~/devel/kernel/linux-fsl-imx51-2.6.31$12:38
* ogra scratches his head12:38
ograi wonder where "iomux_config_mux: Warning: iomux pin config changed" might come from on boot12:38
ograits the very first bootmessage the babbage spits out12:44
ogralool, the regulator errors on bug 438680 look suspiciously like a porting error12:55
ubot4Launchpad bug 438680 in linux-fsl-imx51 "please quieten down bootmessages" [Low,Triaged] https://launchpad.net/bugs/43868012:55
ograi wonder if i should open a new bug for it12:55
ograogra@babbage2:~/devel/kernel/linux-fsl-imx51-2.6.31$ grep -r "with no identifier" drivers/*12:55
ogradrivers/regulator/core.c:printk(KERN_ERR "regulator: get() with no identifier\n");12:55
ogralool, i think bug 439282 should be high instead of medium13:02
ubot4Launchpad bug 439282 in linux-fsl-imx51 "does not power down the system properly" [Medium,Confirmed] https://launchpad.net/bugs/43928213:03
ograwhat do you think ?13:03
=== JamieBennett1 is now known as JamieBennett
loologra: I dont really care beween the two as long as it's fixed   ;-)13:21
loologra: I dont think it's a big deal for a developer board13:21
loolI find it a pain that sound doesn't work because I can imagine people using that for development13:21
loolAnd ethernet not working with NM is also a pain for a desktop use case, since ethernet is in the soc it hits all boards13:22
loolBut wiring of the PMU is likely to differ per board (as it does on lange for instance) so I'm not too concerned that we use power when off; even if it's a bug we should try to fix for release13:22
loologra: Not sure what you want me to do about the regulator stuff?13:23
ogranothing, i want to know if you would consider it better being a separate bug13:25
ograi have no idea what it implies if the code isnt properly integrated with the core kernel regulator code13:26
ograthe messages seem to come from that13:26
loolOh I dont know either13:26
loolprobably best to check with kernle folks13:26
ograyeah13:26
ograwaiting for brad or some other ARM person to get up though13:27
NCommanderogra, I talked w/ cjwatson. The easiest way to get partman-uboot tested is in an alternative CD environment. Probably best if I spend a few cycles working on this with your assistance (as we want alternates anyway ...)13:36
NCommanderer13:37
NCommanderlool,13:37
ograNCommander, but d-i should come up, shouldnt it ?13:37
NCommanderogra, it doesn't get as far as partman13:37
ograwhats the stopper ?13:38
loolNCommander: Well they are mostly working already13:38
NCommanderlool, they are?13:38
loolNCommander: For me alternates worked13:38
loolI think I tested netboot13:38
loolI got the console fonts bug and then the symlink issue IIRC13:39
ogralool, right, cd detection fails on the normal alternates13:39
NCommanderOh, netboot works, but there isn't a way to easily preseed on netboot13:39
ogranetinst should work if you have a working NIC13:40
* NCommander notes that he should probably write a boot.scr for netboot soonish13:40
loolNCommander: Oh and I had to do the cdrom-detect/try-usb=y thing13:40
loolNCommander: There isnt??  I thought there was a preseed file on the CD and it's just a kernel cmdline parameter13:40
loolOh you mean in the image itself; I'm sure we can add that13:41
NCommanderlool, ah :-)13:41
loolNCommander: files are in initrd, so it's probably trivial to add one and add a cmdline arg13:41
NCommanderlool, yeah, I was going to make that change once I sit down and hit d-cd with a shovel13:41
loolit's debian-installer rather13:44
=== jldugger is now known as pwnguin

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