[04:00] hi, would something like this make a suitable board for experimentation? [ebay link] http://tinyurl.com/cnjbgy (3.5" LCD) or http://tinyurl.com/b46hsg (7" LCD) - both are Samsung S3C2440 ARM9 devel boards [04:01] Or does someone have a suggestion for something that has network connectivity and usb host for around $100 USD? [05:54] network and usb host? Linksys NSLU2 [05:55] or a sheevaplug [05:55] both under USD$100 [05:55] talk to lool for ubuntu on nslu2, and rabeeh for sheevaplug :-) === Mirell_ is now known as Mirell [13:35] so would I be making life difficult by experimenting with a paltform like the ones I linked above? [13:54] newz2000, The main tricks with most platforms are 1) making sure there is a clean working kernel, and 2) making sure you have a mechanism to install. [13:54] It's always safer to go with something that someone else already has working, but if you're prepared for the extra work in getting the basics working, anything ought to work. [13:55] ah, good advice. That vendor says they ship with 2.6.13 pre-installed. [13:55] is that helpful? [13:55] Not really. We ship 2.6.28 :) [13:55] yeah, big diff. [13:55] Historically, there's been large, incompatible, patches between different ARM kernel trees as well, which complicates things. [13:57] Maybe I'll have to just wait for the first gen of netbooks and get one of those. I'd kind of like to get something with a screen. [15:25] newz2000: I recommend you look into modern ARM hardware; there's a change Ubuntu might not support older hardware in future releases [15:26] newz2000: Sheevaplug or beagleboard would both qualify I think [15:26] tbm is working on sheevaplug enablement in Debian ATM [15:27] Oh! Marvell released U-Boot and Linux downloads for SheevaPlug [15:27] ah, good tip [15:27] Sheevaplug isnt v7 though [15:27] so might not work in KK [15:27] what are some good search words for the best architectures to use? [15:27] omap3 is surely one ... [15:28] * ogra is a big beagleboard fan [15:28] ogra: Exactly what I was checking; it's just ARMv5 [15:29] How disappointing [15:29] yep [15:29] i hope in KK someone from the community adds beagle support to the linux-ports package [15:29] newz2000: ARMv7? [15:29] that would give us some community [15:30] newz2000: cortex-a8 [15:30] ok, will check it out [15:30] cortex-a8 might be the best [15:30] that specifies all the v7 stuff out there [15:31] the TI zoom looks like a good platform, though the pricing is a joke [15:35] http://www.logicpd.com/products/devkit/ti/zoom_omap34x-II_mdp?DCMP=wtbu_zoom&HQS=Other+PR+orderzoom ... "Starting at $1150 Recommended Resale" [15:58] tbh armv7 is pretty new regarding products using it, if marvell(and therefore almost all NAS vendor) decided to stay with armv5te i'd say its because of something [15:59] well, v7 is what the ubuntu port focuses on [15:59] because ARMv7 license is more expensive than ARMv5 license and for a NAS the ARMv7 provide nothing intersting [16:02] suihkulokki: what does armv7 that armv5 doesn't? [16:10] plans are to go armv7 exclusively (and not hwcap) in karmic? .. [16:34] Hey all. [16:35] The company I work for has gotten a babbage board, and I was wondering if I can run the current armel build of jaunty on it. [16:35] It's all armel, but will the v4 target that ubuntu uses when compiling the dist give me any issues? [16:38] * ogra points Martyn to http://people.ubuntu.com/~ogra/arm/babbage/ [16:38] note its far from being done yet, its only the first handrolled image ... [16:38] ogra: who built that board? freescale? [16:40] armin76, well, who else doe MX$$ CPUs ? :) [16:40] *does [16:43] armin : Pegatron [16:44] the babbage board is basically the same thing as the pegatron netbook, but squashed onto a small devboard. [16:48] ogra : 48 hours old build .. I'm impressed! [16:48] ogra : How long does it take to churn through an entire native build, I wonder... [16:48] ogra : I'll 'dd' up a card and boot it shortly. [16:48] define "native build" :) [16:49] It takes a while to download 800 megs worth of image [16:49] ogra : Non-cross-compiled [16:49] you mean compiling a kernel [16:49] less than 1h [16:49] Oh, so the kernel is compiled on the mx51 board, but the entire distribution outside of it is cross compiled? [16:49] depending on your disk speed ... [16:49] nothing is cross compiled [16:49] Good :) [16:50] the whole arm port is built natively on our arm buildds [16:50] I've been having more and more weird issues with cross compiling on x86 with armel targets. Those problems simply go away when I use a native toolchain. [16:50] currently NCommander is the only one cross compiling something for us, since redboot requires its own special toolchain [16:50] hzzah! [16:50] (and he works on packaging redboot for us atm) [16:51] Awsome. [16:51] why redboot over u-boot [16:51] Well, here does the download. (insert sounds of bandwidth being sucked) [16:51] reboot is more flexible [16:51] because there is no u-boot support for that HW yet [16:51] u-boot has no support on the MX51. [16:51] I thought redboot was no longer being maintained [16:51] redboot is ugly and evil but nobody implemented u-boot for that SoC [16:52] oh ok [16:52] mx31 does that have u-boot support? [16:52] u-boot has the big advantage of being able to just use vfat partitions for kernel and initramfs [16:52] ogra : Wow .. 6mbit of download speed :) [16:52] which means you can just use a vfat /boot partition [16:52] ogra : I love downloading from well hosted servers .. that's close to our office's max theoretical speed [16:53] and dont need to jump through hoops to get your kernel into afis partition or omething equally evil [16:53] ogra : I know, I know. [16:53] Martyn, well, the server is in the canonical datacentre [16:53] * amitk watches ogra's temperature rise a few degrees talking about redboot [16:53] ogra : One of my tasks is to port a more flexible bootloader. [16:53] heh [16:54] Martyn, take u-boot ... many people will love you for it :) [16:54] ogra : If I can convince the VP of engineering here.. sure. [16:54] its the best OSS community maintained bootloader atm [16:54] it's a very flexible one, but I prefer my bootloaders to have more 'smarts' [16:54] it has a big backing by the beagleboard community [16:55] having to type 'mmcinit' .. etc.. is just inane [16:55] so many people look after it and help fixing bugs ... [16:55] (not insane, just boring and technical :) ) [16:55] indeed [16:55] Martyn: what are your options? [16:55] it surely can use some improvement [16:55] I may skip it and port grub. [16:57] I agree u-boot is very popular and quite well maintained [16:58] if you port grub you will be pretty much on your own maintaining the arm specific patches against it for the start ... [16:58] amitk : xosl, grub, u-boot, redboot .. although admittedly there's more work in grub than others, and more work in u-boot than any other for embedded platforms [16:58] u-boot comes with a big community already [16:58] I may just do the 'lazy developer' thing, and extend u-boot to be smarter [16:59] But that totally depends on what the company I'm working for sees as a priority. [16:59] just make u-boot read a config file for the bootcmd :) [16:59] we should store that in a flash partition [16:59] no ! [16:59] can do that. I was just thinking of having it obey the "active" partition label if using PC-style partition labels [17:00] in a text file thats just accessible with an editor ;) [17:00] ogra: that requires an editor inside a bootloader - bloat [17:00] hold on .. I'm downloading the u-boot code. Once I've had a read for a couple hours, I can make more valid comments and directed decisions [17:01] use flash only fro bringing up u-boot, make it read some kind of partition in disk by default and make it read all additional options from atext file in that partition [17:01] amitk : NEVER. [17:01] amitk : It's simpler to just support reading a file off a filesystem. Once the OS is up and running, you use your text editor of choice. [17:01] * amitk agrees [17:01] i.e. make it function similar to grub whithout having to port grub :) [17:01] That's one of the good things about grub, for example. It simply knows to read the FS (not caring much what FS it is .. as long as it's supported) finds the config file, and goes from there. [17:02] right, grub has surely great usability, but u-boot has the biggest bugfixing community backing on arm atm ... [17:02] megre both and you have the perfect arm bootloader ;) [17:02] and as long as the bootloader supports EXT2/3/4, FAT(16/32), and a handful of other commonly used embedded OS'es, then you're fine. [17:03] the bootloader only needs to support one actually [17:03] the problem with grub ATM is that the grub1 is a deadend, grub2 is still not stable [17:03] just to get your kernel up ... [17:03] ogra : Sure, and even keep the filenames. I mean, who cares if the default config file is called "menu.lst"/ [17:03] -heh- [17:04] ogra : I hate having to have two different FS's on a system. Since the bootloader tends to either live in firmware or on the first sector of the disk .. why not just support the most common FS types and get rid of the idea of a special partition for booting... [17:04] sure, but that will make your work bigger [17:04] One of the interesting things about filesystems, is that it's a bitch to create code to support /write/, but reads are actually relatively easy by comparison. [17:04] and most bootloaders don't have the support write for any reason. [17:05] well, you wont need write support at all for the above setup :) [17:05] i already have a code library to deal with NTFS, FAT, FAT16, FAT32(+LBA), EXT(2/3), jffs2, and cramfs [17:05] the system can do all the writing, the bootloader only needs to read [17:05] (and execute accordingly to the config) [17:05] exactly .. I wrote the bootloader for the IBM/Lenovo "blue button" restore system. [17:06] sweet [17:06] And I can say, with PRIDE, all that fits easily in the first 63 sectors. [17:06] The initial bootloader (jump section and some branching code) fits inside the first sector with room for the partition tables :) [17:07] Of course, that's not needed on the ARM platform, which doesn't even load a bootsector from disk, ever. [17:07] One of the same reasons I love the OpenBoot firmware on macs. [17:09] what i really hate about all arm bootloaders in their current state is that you always need a second machine since they all require serial interaction ... [17:12] Hey folks RB actually supports FS [17:12] In tip [17:12] packages/fs/fat/current/src/fatfs.c in ecos [17:13] (Well at least ecos does) [17:42] I have been asking this questions over and over ...Can any1 tell me if any1 was able to get touchscreen working on Jaunty-ARM? [17:42] ??? [17:43] i have it working on a n8x0, but through tslib :P [17:44] I have installed tslib and I also removed synaptic [17:44] But I am still unable to get it to work [17:44] maybe if you tell which hardware you're doing it on :P [17:46] I can do a cat to the touchscreen event and I get characters back...This means my driver is working [17:46] But for some reason I cannot see it on X? [17:47] Any suggestions? [17:47] do you have a /etc/pointercal, since you use tslib? :P [17:47] Yes I calibrated the touchscreen...I got those 4 corners and center hair and it generated /etc/pointercal [17:48] and you got rid of xserver-xorg-input-synaptics (sp) [17:48] yes [17:48] hmm [17:48] But I cannot see anything on X [17:48] cannot see = no actual input working on X, or no cursor showing? [17:49] I mean the touch is not showing an input pointer...However wheneven I touch the screen it takes me to the logout pop-up of LXDE [17:50] no matter where I touch [17:52] and you have an xorg not entirely unlike the inputdevice section in http://rafb.net/p/ghLad128.html ? [17:53] xorg.conf, that is [17:54] Actually I am not using omapfb because my hardware is being almost unresponsive ...So I am using Option "UseFBDev" "true" instead [17:54] well, it was more about the InputDevice section [17:55] Yes ..except that I had to change the event to event1 coz thats where my touch is [17:57] alright.. i would recommend you to check your xorg log for anything weird :P [17:57] Does jaunty have problems in xorg? [17:59] Do you know where the paste bin is ? I wanted to paste the xorg log [17:59] rafb.net/paste can be used [18:00] rafb.net/paste [18:00] How ? [18:01] http://rafb.net/paste paste it, and give the url to the result :P [18:02] http://rafb.net/p/mxDz4Y48.html [18:03] Thanks:) [18:04] and width/height matches resolution? [18:04] can you paste your xorg.conf too? [18:07] xorg.conf: http://rafb.net/p/oyRqch80.html [18:08] hm, seems correct [18:13] and the tslib tools seem to react correctly? [18:13] you mean ts_calibrate [18:13] yes [18:14] i wonder if that stay-clicked touchscreen bug was fixed.. [18:14] what is that bug? [18:15] well there was some bug in -tslib that caused the cursor to stay clicked or something, but im not sure [18:16] Is there another driver that is more stable then with a calibration tool ? [18:16] ok, this is not a official ubuntu package at all, but it is one we use on the nokia n8x0s on a ubuntu port, and i know it works, so you can test if it works with that [18:16] http://repository.mer.tspre.org/pool/main/x/xf86-input-tslib/xserver-xorg-input-tslib_0.0.5-1mer7_armel.deb [18:18] ok Thanks :) I will try it right now [18:18] no promises :P [18:18] can i out of curiousity ask what kind of device you're working with? [18:20] Its a omap3430 device from TI which is not out yet...I cant say more than this ;) [18:20] alright [18:27] ah, and with http://repository.mer.tspre.org/pool/main/t/tslib/libts-0.0-0_1.0-4ubuntu2mer2_armel.deb , http://repository.mer.tspre.org/pool/main/t/tslib/libts-bin_1.0-4ubuntu2mer2_armel.deb too [18:27] forgot those [18:32] ogra : Does the babbage board support SDHC cards properly for booting? [18:33] lool : Sorry it took so long to get back to you .. I was out to lunch, literally. [18:33] that's fine [18:34] Martyn: I have had issues with some versions of redboot with some cards; one limitation is that it will only see the first 2 GB [18:34] So, I can't really comment as to why we have the board .. at least openly. [18:35] Well you're in a public chan here [18:35] So let's avoid it :) [18:35] Right :) [19:10] Aaaand .. after that wonderful netsplit... [19:10] sofi2: any luck? [19:10] ogra : The image starts at block 4, so you've left room for redboot at the top of the image? [19:10] Or does the image have a reboot already on it? [19:11] I just did the dd and inserted the card, but got no joy for a boot. [19:30] Stskeeps: I am still unable to get touch working? [19:31] sofi2: alright, - i'm not entirely sure what is wrong then :/ [19:37] * Martyn gives up on the board for the moment, and moves back to working on the beagleboard. [19:53] One of these days, installing ubuntu on non-x86 architectures will be as easy as installing it on x86 [19:54] * Martyn *sighs* It just doesn't have to be this hard. [21:26] is there anyone here with a babbage board that could do a quick off-channel chat to check board DIP switch settings [21:26] Since I'm short the docs, I just want to get this one in a bootable state. [21:41] re === ian_brasil is now known as ian_brasil_ack === ian_brasil_ack is now known as ian_brasil [22:08] Hi there David [22:08] hello === Nicke_ is now known as Nicke [23:54] re