=== DanaG1 is now known as DanaG
[05:15] <DanaG> nice... the kernel on my beagleboard just segfaulted.
[05:17]  * DanaG wishes there were a board that had a superset of "openrd-base" and "openrd-client".
[05:17] <DanaG> Base doesn't have many USB ports, but client doesn't have PCIe slot.
[05:18] <persia> What we need is some good way to share open board layouts, and a contract assembly plant with quick turnaround.
[05:21] <DanaG> The openrd-client would be perfect if not for that stupid onboard XGI.
[05:22] <DanaG> With a PCIe slot, instead, we could stick an ATI card in there and have arm eyefinity. =þ
[05:27] <persia> Or just add a USB hub to openrd-base
[05:36] <DanaG> Does the client use a hub, or 4 real separate ports?  I'm not quite sure how that works.
[05:37] <DanaG> Even on an ordinary x86 system... is there any difference between 4 ports off the root, versus 4 ports on a hub off one root port?
[05:38] <DanaG> Base also doesn't have audio, rs485 (not that I'd know what to do with it), or the second GbE connector.
[05:40] <persia> Audio is trivial: use USB.
[05:40] <persia> I'm not sure of the implementation, but I suspect it's an internal hub, rather than real separate ports.
[05:40] <persia> Except for drives, this doesn't typically matter all that much.
[05:41] <DanaG> hmm, I wonder which would have better quality... onboard, or USB?  I doubt many SOCs have 24/96 abilities. =þ
[05:41] <DanaG> s/many/any/
[05:44] <DanaG> hmm, looking at the block diagram, it does look like merely an onboard hub.
[05:45] <DanaG> http://www.globalscaletechnologies.com/t-openrdbdetails.aspx#hw_block
[05:45] <DanaG> http://www.globalscaletechnologies.com/t-openrdcdetails.aspx#hw_block
[05:46] <persia> That's common.  It's a cheap component, and adds perceived value to a board if there's leftover space.
[05:46] <DanaG> also weird... base block-diagram shows only esata... yet manual shows an onboard sata as well.
[05:46] <persia> Real ports typically have to be in the SoC directly, so it's rare to not get the same number on every board for a given SoC.
[05:47] <persia> (well, some boards trim them, but usually at least provide headers when they do)
[05:47] <DanaG> The real bummer is the loss of that second GbE.
[05:47] <persia> "onboard sata" might be a USB-SATA interface on the board.
[05:47]  * persia has heard of that on a few boards now
[05:48] <DanaG> nope, the block diagram in the openrd-base manual (pdf) shows sata-#1 internal and sata-#2 esata.
[05:49] <persia> That's just branding.  The difference between "SATA" and "eSATA" is the plug.
[05:49] <DanaG> heh, every time I see "OpenOCD", I think "Open Obsessive-Compulsive Disorder"
[05:49] <persia> Does it have a header, if it doesn't have a plug?
[05:50] <DanaG> openrd-client block diagram on web site: 2 sata connectors (one internal, one external).  openrd-base on web page: 1 sata.  OpenRD-Base PDF: 2 sata.
[05:50] <persia> Hurrah for communication between the tech writers and the marketing dept.!
[05:50] <DanaG> Oh, and a handy hint for win7: there are built-in "RNDIS-Compatible" drivers that work perfectly... and are signed.
[05:51] <DanaG> Just have to uncheck "show only compatible drivers".
[05:52] <DanaG> It's likely they revised the product at some point, and forgot to update the web site.
[05:58] <DanaG> Revision log in the PDF shows only one version... so I wonder which is the current state: one port, or two?
[06:16] <DanaG> NetworkManager: <WARN>  wireless_get_range(): (wlan0): couldn't get driver range information (95).
[06:16] <DanaG> NetworkManager: <WARN>  constructor(): (wlan0): Device unsupported, ignoring.
[06:20] <DanaG> grr, stupid networkmanager,
[06:20] <DanaG> .
[06:35] <DanaG> wlan0     Interface doesn't support scanning.
[06:35] <DanaG> nice job, kernel.
[06:42] <DanaG> /boot/config-2.6.34-rc4-l0:# CONFIG_CFG80211_WEXT is not set
[06:42] <DanaG> /boot/config-2.6.33-500-omap:# CONFIG_CFG80211_WEXT is not set
[06:52] <DanaG> hmm, the omap kernels seem all screwed up to various degrees.
=== nslu2-log_ is now known as nslu2-log
=== lool- is now known as lool
=== rsalveti_ is now known as rsalveti
[13:27] <RoyK> hi all. I'm thinking of using ubuntu on a Moxa box - is this likely to function well?
=== ynezz_ is now known as ynezz
[13:40] <rcn-ee> Which Moxa box? (model #)
[13:41] <RoyK> erm - don't remember - I just found out ubuntu supports arm... it'll be a new model. don't they all use arm7?
[13:43] <rcn-ee> nope..  always look closely, it looks like (moxa.com) is an xscale house which is old armv5 hardware, which would mean Jaunty only. (bring your own kernel off course)
[14:28] <saeed> asac: ping?
[17:37] <philo> hi have a arm related but non ubuntu related question
[17:37] <philo> can someone confirm that "ldr <register> , = <expression>" is a valid opcode for gas ?
=== TheWhiteGhost_ is now known as TheWhiteGhost
[19:10] <rcn-ee> DanaG, i just enabled CONFIG_CFG80211_WEXT it'll be on my 2.6.33.2-dl7 uploads..
[19:10] <DanaG> Cool.
[19:11] <DanaG> Oh yeah, which time-zone are you in?
[19:11] <rcn-ee> us central..
[19:11] <DanaG> ah.
[19:31] <DanaG> Cool, thanks.
[19:31] <DanaG> Do you have a kernel somewhere that's compiled with musb_hdrc built-in and yet all the g_ether and such built as modules?
[19:38] <rcn-ee> kinda...  I have too many Bx boards, so i don't build that way: but the config diff is located here: http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/annotate/head:/patches/rcn/002-defconfig-disable_gadget_stuff.diff  just use that to change patches/lucid-defconfig in my 2.6-stable repo
[19:41] <rcn-ee> andruk, it seems to work: /dev/spidev3.0  /dev/spidev3.1  /dev/spidev4.0
[20:09]  * XorA|gone wonders why so many segfaults :-(
[20:16] <XorA|gone> rcn-ee: is there any kernel config stuff you can think of that would make apt/dpkg segfault a lot?
[20:16] <XorA|gone> rcn-ee: Angstrong is rock solid on this kernel
[20:16] <rcn-ee> yeap.. that sounds like the thumb erata..
[20:17] <XorA|gone> you guys are using thumb?
[20:17] <persia> XorA|gone: To test, does karmic run clean, and just lucid segfault (karmic was -marm)
[20:17] <rcn-ee> make sure: CONFIG_ARM_ERRATA_430973=y is set...  lucid is thumb2...
[20:18] <rcn-ee> all r1pX cores such as the omap35x need it..
[20:18] <XorA|gone> rcn-ee: ah cool, Angstrom ditched thumb as it was too unreliable with a lot of gcc/binutils mixes
[20:19] <persia> One of the luxuries of being able to specify the use of the native internal toolchain :)
[20:19] <rcn-ee> yeap, i know what you mean.. i started with angstrom too..  the ubuntu guys wanted to try it. ;)
[20:19] <persia> It's (mostly) working for us, after we ported a heap of apps.
[20:20] <XorA|gone> persia: that doesnt help, we found many many glaring bugs in binutils
[20:20] <persia> XorA|gone: Do you know if they have been fixed?  I know we carry some patches.
[20:20] <XorA|gone> I think they finally got fedup of us bitching though, recent ones work a whole lot better
[20:20] <persia> If not, that might be unfortunate.
[20:20] <persia> I suspect that's the case (and thanks for the complaints :) )
[20:21] <XorA|gone> we use Phil Blundel to do our nagging :-)
[20:22] <XorA|gone> anyway I am off to check my defconfig
[20:22] <XorA|gone> lucid working nice on zoom2 apart from segfaults though
[20:24] <rcn-ee> that sounds like the config... other then segfaulting most things will still run...
[20:25] <rcn-ee> i ran into it in teh early alpha1-2 days since i was runing deb-pkg on top of fakeroot, and fakeroot was segfaulting..
[20:29] <XorA|gone> rcn-ee: do you have all 3 erratas turned on?
[20:29] <rcn-ee> no, i haven't ran into needing 458693 or 460075 yet
[20:30] <XorA|gone> rcn-ee: just found your defconfig
[20:30] <rcn-ee> CONFIG_ARM_ERRATA_430973: ARM errata: Stale prediction on replaced interworking branch
[20:30] <rcn-ee> basicly if you have thumb binary and arm binary running, something bad could happen..
[20:31] <XorA|gone> yeah I remember the discussion on linux-omap now
[20:31] <XorA|gone> I just forgot as we dont use thumb
[20:32] <rcn-ee> yeap, it only came into play with lucid..  but i had to go back and enable the option for all since my builders run squeeze and build all distro's in chroots...
[20:35]  * XorA|gone feels lucky this compile isnt being done on the zoom2 :)
[20:35] <rcn-ee> it only takes 5ish hours with all modules.. ;)
[20:37]  * XorA|gone curses and hunts who broke OE
[20:38] <XorA|gone> ah my bad, I acked the patch :-)
[20:49]  * XorA|gone notices ubuntu needs a rule in udev to link /dev/fb0 to /dev/fb
[20:51] <persia> What unfixably depends on /dev/fb ?
[20:52] <XorA|gone> persia: well you could patch xserver-video-omapfb (and omap3 version) to look properly
[20:52] <persia> That sounds less invasive (only affects the one bit that has issues).
[20:52] <persia> Does a patch exist?
[20:53] <XorA|gone> persia: no, as we just create the link
[20:53] <XorA|gone> persia: I will get tasked with that eventually by TI more than likely
[20:53] <persia> heh, OK.
[20:54] <persia> The alternative would be to have the xserver-xorg-video-omapfb package install a udev rule, but that feels hacky.
[20:54] <persia> (on the other hand, it's probably faster)
[20:54] <persia> dh_installudev ought give you the hints to do that easily.
[20:56] <persia> But we should avoid patching udev, as folks on other platforms don't need/want the link.
[21:01] <XorA|gone> persia: yeah, I see that
[21:01] <XorA|gone> I think the issue is the meanings on the fb's is kind of hardcoded into omap3
[21:02] <XorA|gone> fb1 fb2 are the hardware overlays for video
[21:06] <XorA|gone> rcn-ee: thanks, looking a lot better now
[21:07] <rcn-ee> good to hear XorA|gone
[21:08] <XorA|gone> just two bugs to figure out on zoom2 and its usable
[21:08] <rcn-ee> which two are left?
[21:08] <XorA|gone> touchscreen is uncalibrated and keyboard is not working
[21:09] <XorA|gone> usb keyboard is working, so it must be something simple
[21:30] <persia> Does the driver provide a /dev/input/event interface?
[21:39] <XorA|gone> persia: I think so, Im pretty sure its some minor issue, its working in poky and angstrom with xorg 1.8 with no patches
[21:40] <persia> I'm just wondering if it's a side-effect of Ubuntu's attempts to not use xorg.conf
[21:41] <persia> Lots of stuff that works just fine needs tweaking to work in Ubuntu due to needing to fit into autodetection
[21:41] <XorA|gone> ah crap, it could be a rule missing from hal/libudev so it doesnt ID it as a keyboard
[21:41] <XorA|gone> we use autodetection as well
[21:41] <persia> Right.  I thought I remembered ndec saying something about the zoom2 keyboard being a bit funny.
[21:42] <XorA|gone> I dont remeber us having a custom rule, but its possible we do
[21:42]  * XorA|gone adds it to the list
[21:42] <persia> Oh, and in case you didn't notice, hal has been deeply stripped in Ubuntu as part of the efforts to make it go away entirely, so if you're depending on HAL behaviour, you mayfind it differs.
[21:43] <XorA|gone> persia: there is a dev branch of Angstrom that is nearly totally hal gone, so we should be about the same level
[21:44] <XorA|gone> persia: it will be some minor tweak Im sure
[21:44] <persia> Probably.  Glad to hear that Angstrom is dropping HAL also: it always feels better to be part of the crowd :)
[21:44] <XorA|gone> Ill be sure to post patches when I actually start coding on this
[21:46] <XorA|gone> BTW is there any plans to make Lucid initialise the OTG port on boot?
[21:46] <persia> I doubt it.  Lucid is in final-freeze.
[21:46] <XorA|gone> ok
[21:46] <persia> So only RC stuff is getting pushed at this point.
[21:46]  * XorA|gone is still a little upset at the EHCI port on his beagle burning out
[21:47] <persia> Understandably.
[21:48] <DanaG> Hmm, so will it end up still having that kernel oops (and segfault on reboot)?
[21:48] <DanaG> That's what I get with the Lucid kernel on my beagle.
[21:48] <persia> DanaG: Which bug #?
[21:48] <DanaG> erm, lemme' see if there is one.
[21:49] <persia> I promise that if there's not a bug, there's no chance it will be changed for lucid :)
[21:51] <DanaG> What's the plan for officially installing the ubuntu kernel?  Will it have an equivalent of update-grub?
[21:51] <persia> No.
[21:52] <persia> But that's mostly because update-grub does a very different thing than is currently suitable
[21:52] <persia> (someone should port grub and fix this)
[21:52] <DanaG> Hmm, bummer.  it'd be nice to have it auto-copy uimage to the fat16 partition.
[21:52] <DanaG> that's what I meant.
[21:52] <DanaG> yeah, I guess that is way different from grub, after all.
[21:52] <persia> DanaG: Well, flash-kernel can do some of that: it's designed to copy the kernel from /boot to somewhere else for devices that don't have decent bootloaders.
[21:53] <XorA|gone> hmm, zoom2 keyboard decides to work again
[21:53] <persia> And I believe the kernel calls flash-kernel on postinst.
[21:53] <persia> XorA|gone: heisenbug?
[21:54] <DanaG> I also figured out something interesting with my asix ethernet:
[21:54] <XorA|gone> persia: maybe the driver went wrong due to that thumb issue
[21:54] <DanaG> The thing that was making it not work on boot... was that I had "ethtool -s eth0 wol g" in rc.local.
[21:54] <persia> Ah, that might be it.
[21:54] <DanaG> Apparently enabling WOL kills asix.
[21:54] <XorA|gone> so just touchscreen
[21:54] <XorA|gone> and the patch Angstrom has for that is not suitable upstream
[21:54] <persia> What's the issue with touchscreen?
[21:55] <XorA|gone> I beleive it thinks its a touchpad, not a touchscreen
[21:55] <XorA|gone> but its how to tell libudev how to properly identify them
[21:55] <persia> Oh, yeah.  The Netwalker has the same issue.
[21:56] <persia> The (hacky) solution in the netwalker was to just hint the synaptics driver when the device was discovered in HAL.
[21:56] <persia> But that's 9.04.
[21:56] <persia> For lucid, you might get away with the same trick in udev.
[21:56] <XorA|gone> koen did a hack where if driver returns pressure use tslib
[21:56] <persia> (but better to fix properly, if one can)
[21:57]  * XorA|gone will talk to hrw he had similar issues with bug which he might have fixed
[21:57] <persia> That's a plan :)
[21:58] <XorA|gone> not as fast as that omap4 board, but speed isnt bad on the UI :)
[22:02] <persia> Everyone fusses about speed, but really, unless you're doing something especially complex (like rendering multi-input graphic interfaces in realtime: e.g. web browsing), most stuff doens't really need a high-spec processor.
[22:08] <DanaG> wlan0     Interface doesn't support scanning.
[22:11] <DanaG> ah. here's my oops: https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/563650
[22:11] <ubot4> 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: 8)" [Medium,Confirmed]
[22:12] <persia> DanaG: OK.  That's been determined to not be release-critical: it's scheduled for a post-release update.
[22:12] <persia> (milestoned against lucid-updates)
[22:13] <DanaG> Ah, the only other big thing is "iwlist s" not working -- probably due to WEXT being disabled.
[22:13] <DanaG> /boot/config-2.6.33-500-omap:# CONFIG_CFG80211_WEXT is not set
[22:13] <XorA|gone> DanaG: same ooops present on zoom2
[22:15] <DanaG> NetworkManager: <WARN>  wireless_get_range(): (wlan0): couldn't get driver range information (95).
[22:15] <DanaG> NetworkManager: <WARN>  constructor(): (wlan0): Device unsupported, ignoring.
[22:18] <XorA|gone> well thats me happy for tonight, thanks for the help guys
[22:19] <DanaG> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/566238
[22:19] <ubot4> Launchpad bug 566238 in linux-ti-omap (Ubuntu) "wlan0 "Interface doesn't support scanning." -- CONFIG_CFG80211_WEXT is not set (affects: 1)" [Undecided,New]