| 00:09.36 | ds2 | back to the grindstone |
| 00:32.11 | ds2 | the hammer MTD numbers do not add up |
| 00:34.13 | ds2 | nevermind, math error |
| 00:42.48 | *** join/#edev redb1ue (i=star@ppp050.109-253-207.mtl.mt.videotron.ca) |
| 00:46.40 | *** join/#edev redblue (i=star@ppp050.109-253-207.mtl.mt.videotron.ca) |
| 01:14.51 | *** join/#edev sunrunner20|prom (n=jamesdoe@pool-96-226-67-104.dllstx.fios.verizon.net) |
| 01:16.35 | sunrunner20|prom | 2wks 5hrs 5mins 37secs |
| 01:17.28 | sunrunner20 | why the *#$&)#)*#)#)# do i have a 1SECOND ping |
| 01:17.29 | sunrunner20 | >_> |
| 01:18.04 | sunrunner20 | POS router |
| 01:30.19 | *** join/#edev dbtid (i=eykg3pb1@cpe-65-24-173-154.columbus.res.rr.com) |
| 01:30.31 | dbtid | hello. anyone around to talk about prelinking for an ARM target? |
| 01:30.47 | dbtid | i'm building the app under OE, and i'm trying to figure out how to prelink my application. |
| 01:30.51 | ds2 | i do not like this behavior... a second xmodem transfer fails but right after rebooting, it works :( |
| 01:31.02 | ds2 | dbtid: on the host or target? |
| 01:31.24 | dbtid | ds2: i'd like to run the prelinking on the host against the binary for the target. |
| 01:31.50 | ds2 | dbtid: I have only see it done on the target itself |
| 01:31.54 | dbtid | ok |
| 01:32.07 | dbtid | i can go get the prelink sources, build them for my target, and see what happens. |
| 01:32.19 | dbtid | i COULD also try to find the /lib for the target in OE |
| 01:32.24 | dbtid | hmm |
| 01:34.05 | ds2 | there probally is a way of doing it, just never tried |
| 01:34.12 | ds2 | worse case I suppose is to do it in qemu |
| 01:34.27 | dbtid | i don't know how to fire up qemu for this target |
| 01:34.32 | dbtid | i know it's part of OE |
| 01:35.05 | dbtid | hrm |
| 01:35.11 | dbtid | $TARGET_LDFLAGS |
| 01:35.16 | dbtid | is set by devshell |
| 01:35.19 | dbtid | i'm guessing that's the start |
| 01:35.24 | dbtid | brb |
| 01:40.45 | *** join/#edev [g2] (n=tom@nslu2-linux/g2) |
| 02:03.15 | *** join/#edev dijenerate (n=dijenera@65.48.164.209) |
| 02:13.49 | ds2 | xmodem is so broq |
| 02:17.12 | dbtid | ds2: do you have any idea how prelink was built for the target? |
| 02:17.22 | ds2 | nope, I don't use OE |
| 02:18.38 | dbtid | thanks |
| 02:38.49 | ds2 | the hammer is the most troublesome platform todate :( |
| 02:41.39 | ds2 | either that or the xmodem in busybox is a PoS |
| 02:55.32 | solar | ds2: managed to get a firmware made out of that thing uploaded? |
| 02:56.42 | ds2 | nope |
| 02:56.53 | ds2 | just having a whole brew of problems |
| 02:57.04 | ds2 | 1. Xmodem in busybox blew up in 23432414190849023849081409840981049840923 ways |
| 02:57.17 | ds2 | 2. JFFS self corrupted itself enough to autopanic and corrupt files |
| 02:57.34 | ds2 | oh and APEX does not like large file downloads either |
| 02:57.35 | dbtid | ow |
| 02:57.56 | ds2 | it was NOT this troublesome getting stuff onto the gumstix |
| 03:00.27 | ds2 | think right now the count stands at 4hr+ fighting with xmodem/jffs/apex |
| 03:00.44 | solar | no other method to flash it? |
| 03:01.00 | ds2 | I was trying to avoid installing openocd and getting the flyswatter up |
| 03:01.05 | ds2 | that's what I am trying now |
| 03:01.19 | ds2 | I should not need to get jtag going to just put in a rootfs! |
| 03:02.45 | ds2 | GRRRR |
| 03:03.37 | ds2 | @#%$$#@$%$ PoS |
| 03:04.26 | ds2 | strike 1 on openocd...damn binary ftdi modules |
| 03:06.45 | ds2 | strike 2, it just don't find it |
| 03:14.04 | ds2 | strike 3: openocd can't even see the flyswatter |
| 03:16.33 | solar | I'll testing that image on my nail for the just in case backup method |
| 03:17.56 | ds2 | I can't believe this is going this wrong. It was suppose to be a simple Xmodem download of a few files now it has gone from busybox xmodem blowing up all the way to openocd blowing up |
| 03:18.53 | dbtid | can you compile a standard xmodem and get it in via flash? |
| 03:19.28 | ds2 | there lies the problem, the initrd on there is using some odd uClibc config and to do that, I would need to tug at another long yarn |
| 03:19.38 | dbtid | i see |
| 03:19.55 | ds2 | Okay, the cut off is midnight monday, if it does not all work, the hamer goes away |
| 03:20.59 | solar | thats not fun. |
| 03:21.04 | solar | are you on a strict deadline? |
| 03:21.15 | ds2 | I have to have everything working by Wednesday |
| 03:21.28 | ds2 | I still got a panel to machine along with the beagle side to configure |
| 03:21.54 | ds2 | so the plan after Monday midnight is to ducttape in a gumstix and be done with |
| 03:22.02 | solar | well if it comes down to it I can lend you this nail easy enough to quick reflashing. |
| 03:22.18 | ds2 | ugly but the amount of problems is redicious |
| 03:22.39 | ds2 | I can't believe 4.5 hours into this and I am still trying to get it flashed :( |
| 03:23.14 | ds2 | I don't think it is a nail or a hardware thing; right now openocd is saying there is no such command as "erase_sector" used in the scripts on elinux.org |
| 03:23.43 | solar | oh |
| 03:23.46 | ds2 | but I am somewhat glad that's the case, as the erase command looks like is setup to blow away all of flash, and I don't want that |
| 03:23.57 | solar | ok |
| 03:24.08 | solar | you have a newer openocd like svn? |
| 03:24.20 | ds2 | nope, I am using everything from the elinux.org page |
| 03:24.42 | solar | what arch are you on? |
| 03:24.54 | ds2 | the monkey wrench here is I am on a 64bit system so it had to be built with -m32 to keep ftdi happy which I found out wants root |
| 03:25.03 | ds2 | x86_64 is my host |
| 03:25.30 | ds2 | but it should not be missing commands(!); and typos in the how to compile openocd docs did not help |
| 03:25.33 | solar | want my openocd.bin + updated openocd files for the renamed syntax? |
| 03:25.50 | ds2 | sure, I'll try anything |
| 03:26.24 | ds2 | is the new syntax still based on sectors or can it take bytes? |
| 03:30.28 | solar | ds2: dev.gentoo.org/~solar/embedded/tct/ds2.tar.bz2 |
| 03:30.36 | solar | should have everything just incase. |
| 03:31.03 | ds2 | got it |
| 03:31.11 | *** join/#edev DrZimmerman (n=theo@77-56-242-58.dclient.hispeed.ch) |
| 03:31.36 | ds2 | there is a 64 bit ftdi driver... |
| 03:34.31 | solar | yeah EM_X86_64 ./kernel/drivers/usb/serial/ftdi_sio.ko |
| 03:34.41 | ds2 | Solar: that's no good. lrwxrwxrwx 1 ds2 ds2 17 Sep 28 20:32 libftdi.so.0 -> libftdi.so.0.10.0 |
| 03:34.47 | ds2 | and the actual file is not there |
| 03:34.49 | solar | ahh sec. |
| 03:34.53 | solar | cp -a :) |
| 03:36.13 | ds2 | I see you are packing the kernel in |
| 03:37.17 | solar | in the flashme? yeah it's easier that way |
| 03:37.36 | ds2 | I am trying to keep the initrd around for sanity reasons |
| 03:37.43 | ds2 | should be a easy change |
| 03:39.34 | solar | reuploaded |
| 03:41.13 | ds2 | this is getting funnier... "Floating point exception" :) |
| 03:41.26 | solar | oh your box when running that openocd? |
| 03:41.30 | ds2 | yep |
| 03:41.48 | solar | hrmm sec. Let me see what flags I compiled it with |
| 03:42.12 | ds2 | it is probally a library thing |
| 03:42.13 | solar | dev-embedded/libftdi-0.10: -O2 -pipe -march=nocona |
| 03:42.40 | ds2 | I am forcing it to search the tarball libs first with LD_LIBRARY_PATH and that's probally not happy with my other libs |
| 03:42.42 | solar | I can dump the -march and rebuild if it will help ya |
| 03:43.17 | ds2 | let me test out a theory - the elinux.org tarball might be old so let try the old flash erase insetad of the newer flash erase_sector |
| 03:44.06 | ds2 | it got further now |
| 03:45.24 | ds2 | now it is write_bank |
| 03:46.49 | solar | does 'flash write_bank' work? |
| 03:47.05 | ds2 | nope, changed to 'flash write' and trying that now |
| 03:47.19 | ds2 | it is seeming like the elinux.org tarball is very old |
| 03:47.33 | ds2 | and doesn't match the config/script files on the same page! |
| 03:48.19 | ds2 | flash write is doing something |
| 03:49.59 | solar | hrmm don't think the nail's kernel is eabi+oabi but does not seem happy about that userland for me. |
| 03:50.51 | ds2 | kernel don't like the image :( |
| 03:51.31 | solar | I mean I have eabi+oabi-compat. It's been running in compat most but this is the first try at the eabi on the nail |
| 03:52.18 | solar | probably not tonite but I'll try a pure eabi kernel w/o oabi-compat |
| 03:52.39 | ds2 | that'd be good... the implements claim oabi-compat is seriously buggy |
| 03:52.56 | ds2 | and from what I have seen on another board, I would agree |
| 03:53.25 | ds2 | operator error on that one... a .tar.bz2 file does not mount well as jffs2 ;) |
| 04:01.12 | ds2 | solar: got the openocd to write the immage... but the image don't boot. missing /dev entires it seems. will look at it in a few mins. |
| 04:06.09 | ds2 | found the problem mdev is broq |
| 04:07.24 | solar | how so? |
| 04:07.52 | ds2 | not sure exactly but what looks like is happening is init mounts tmpfs on /dev, /dev disappears and mdev never rebuilds it |
| 04:08.16 | ds2 | cuz I get a flurry of cannot open /dev/null and /dev/ttySAC0; those go away once i disable the mount and mdev in inittab |
| 04:08.55 | solar | that sounds about what would happen cuz the image should contain /dev/ttySAC0 |
| 04:09.10 | ds2 | the image contains /dev/ttySAC0 and /dev/null |
| 04:09.20 | solar | so. see the etc/mdev.conf |
| 04:09.35 | ds2 | but they go away as soon as init hits: null::sysinit:/bin/mount -n -t tmpfs -o "exec,nosuid,mode=0755,size=10M" mdev / |
| 04:10.17 | ds2 | mdev mentions SAC but no null |
| 04:10.51 | ds2 | take that back, there is a null |
| 04:10.51 | solar | right. So I bet if we change it to it's full /dev/serial_s3c24xx name it would be happy |
| 04:11.01 | solar | but I swear I had some symlinks setup for that |
| 04:11.13 | ds2 | there is a lot of stuff complaining |
| 04:11.18 | ds2 | don't matter, I like static /dev's |
| 04:12.22 | solar | get it to run the first time and you will have the perfect static-dev :) |
| 04:12.53 | solar | so it ran. It just sounds like the wrong console name |
| 04:13.14 | solar | which is probably due to this silly mdev.conf bug |
| 04:13.30 | solar | in the mdev.conf there will be an extra ; field in my conf you will see |
| 04:13.39 | ds2 | *nod* I just don't mount tmpfs on /dev or run mdev |
| 04:14.07 | solar | it might of been uclibc only. I'm not sure. But the extra ; thats the 4th field might need to not be there |
| 04:14.35 | solar | I'm going it for a kinda hotplug action |
| 04:14.36 | ds2 | don't see any extraeous ';' |
| 04:14.53 | ds2 | useful if the hardware is going to change, my hardware is as static as they come |
| 04:15.00 | solar | s3c2410_serial[0-9] 0:20 0600 ; @ln -sf $MDEV ttySAC$(echo $MDEV | cut -c 15-) |
| 04:15.03 | solar | would become |
| 04:15.09 | solar | s3c2410_serial[0-9] 0:20 0600 @ln -sf $MDEV ttySAC$(echo $MDEV | cut -c 15-) |
| 04:15.26 | solar | has to be done for the entire file or mdev gets unhappy |
| 04:16.53 | ds2 | I'll give it a try; want to sanity check things |
| 04:17.20 | solar | cat mdev.conf | cut -d ' ' -f 1-3,5- > mdev.conf~;mv mdev.conf{~,} |
| 04:17.57 | ds2 | it was short enough I did it by hand, search for '; @' then do 'xn' and repeat |
| 04:18.04 | solar | ahh nope. that will syntax err |
| 04:33.52 | solar | hrmm yeah I seem to be hitting the same errors now. yep best go with that static dev for now |
| 04:49.29 | ds2 | =) |
| 04:50.53 | ds2 | think my blood pressure is has dropped an order of magnitude in the last hour |
| 04:54.20 | solar | got a login prompt now? |
| 04:54.33 | ds2 | yeah, I been testing the peices |
| 05:00.48 | solar | interesting. |
| 05:00.58 | ds2 | other stuff broken? |
| 05:01.09 | solar | and you are using the hammer right with that eabi userland? :) |
| 05:01.15 | ds2 | yes |
| 05:01.20 | ds2 | but i am using my own kernel |
| 05:01.21 | ds2 | =) |
| 05:01.25 | solar | congrats. you are the first |
| 05:01.31 | ds2 | Oh?! |
| 05:02.04 | *** join/#edev magnetron (n=magnetro@unaffiliated/magnetron) |
| 05:02.05 | ds2 | the good thing with eabi is I should be able to copy the binaries to the newer stuff and expect it to work |
| 05:02.26 | solar | yeah. so far it's all been ppl doing uclibc |
| 05:02.57 | ds2 | Hmmmm |
| 05:03.40 | solar | this means I'll have to give arm*-softfloat-linux-uclibcgnueabi a spin soon with uClibc-0.9.30-rc1 |
| 05:03.46 | ds2 | Having had some time to cool down, I think the docs needs to be better (at least not have errors or inconsistancies) |
| 05:34.18 | *** join/#edev edrick (n=chatzill@61.11.44.159) |
| 05:36.32 | *** join/#edev archaeptery1 (n=snewman@207.47.42.130.static.nextweb.net) |
| 05:38.52 | solar | ds2: can you post your kernel.config |
| 05:39.08 | ds2 | sure, where would you like it? |
| 05:39.39 | solar | http://anywhere/~ds2/kernel-foo.config |
| 05:39.45 | solar | wget :) |
| 05:39.50 | ds2 | ok |
| 05:41.54 | ds2 | http://www.ugcs.caltech.edu/~huny/hammer-config |
| 05:43.27 | ds2 | there is something wrong with jffs2 on this kernel :( |
| 05:51.52 | solar | apex.bin ? |
| 05:51.52 | solar | you got the right jazz all setup there? |
| 05:51.53 | ds2 | no, I am getting errors when writing to jffs2 |
| 05:51.53 | ds2 | probally a patch somewhere... I've moved /var/log onto tmpfs as a work around ;) |
| 05:51.54 | solar | oh yeah. It's suppposed to be |
| 05:51.54 | ds2 | oh... then that's another bug |
| 05:51.54 | *** part/#edev pea (n=pea@75.58.4.163) |
| 05:51.54 | solar | dirs that my cleanup script should be making symlinks to /tmp/ |
| 05:51.54 | solar | <PROTECTED> |
| 05:51.56 | ds2 | <PROTECTED> |
| 05:51.56 | solar | http://linbsd.net/~solar/config.diff http://dev.gentoo.org/~solar/embedded/tct/apex-1.5.6-jffsroot.config |
| 05:52.31 | *** join/#edev mbuf (n=user@61.16.248.242) |
| 05:53.58 | ds2 | is that suppose to be an optimized version of my config or? |
| 06:02.30 | *** join/#edev edrick_ (n=chatzill@61.11.44.159) |
| 06:11.10 | solar | nope. Just mine for the nail. |
| 06:11.43 | solar | I find it handy to look at others for the features they use |
| 06:12.03 | solar | plus now I know why my eabi user land for sure did not work |
| 06:19.50 | *** join/#edev methril (n=Methril@213.27.233.98) |
| 06:20.24 | methril | yo |
| 06:22.53 | solar | evening |
| 06:28.47 | ds2 | the EABI setting in the kernel? |
| 06:31.26 | solar | yep yep. about to upload a new image |
| 06:40.30 | solar | nice. got it working also now |
| 06:47.31 | solar | hrm. 'file' acts funny cross compiled. |
| 07:11.36 | *** join/#edev [AD]Turbo (n=turbo@host116-243-dynamic.1-87-r.retail.telecomitalia.it) |
| 07:12.34 | [AD]Turbo | yo |
| 07:20.46 | *** join/#edev boris_OmegA (n=boris@194.51.141.172) |
| 08:20.58 | *** join/#edev likewise (n=likewise@82-171-51-231.ip.telfort.nl) |
| 09:10.01 | *** join/#edev harpal (n=Harpal@122.169.108.195) |
| 09:24.33 | *** join/#edev lyakh (n=lyakh@p57BD091B.dip0.t-ipconnect.de) |
| 10:38.53 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 11:05.25 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 11:15.36 | *** join/#edev g1powermac (n=g1powerm@unaffiliated/g1powermac) |
| 11:23.50 | *** join/#edev likewise (n=likewise@82-171-51-231.ip.telfort.nl) |
| 12:04.00 | *** join/#edev [g2]_ (n=tom@cpe-071-070-217-085.nc.res.rr.com) |
| 12:33.10 | *** join/#edev GPSFan (n=kenm@64.92.145.112) |
| 12:33.10 | *** mode/#edev [+o GPSFan] by ChanServ |
| 13:20.35 | *** join/#edev prpplague (n=dave@mail.americanmicrosystems.com) |
| 13:30.33 | prpplague | ds2: alive yet? |
| 13:47.01 | *** join/#edev chouimat|work (n=dieu@209.217.106.98) |
| 14:18.59 | *** join/#edev g1powermac (n=g1powerm@unaffiliated/g1powermac) |
| 14:27.23 | *** join/#edev adyer (n=adyer@adsl-69-223-13-78.dsl.chcgil.ameritech.net) |
| 14:34.37 | *** join/#edev g1powermac_PB (n=g1powerm@unaffiliated/g1powermac) |
| 14:40.10 | dbtid | root |
| 14:40.44 | prpplague | dbtid: beer |
| 14:40.51 | dbtid | prpplague: hack |
| 14:41.14 | dbtid | this network setup for work that i'm using is all goofy |
| 14:41.23 | dbtid | and then my mouse strayed into this window |
| 14:41.36 | dbtid | and then it didn't shift focus OUT when i moved the mouse loke it's supposed to :) |
| 14:44.39 | solar | morn |
| 14:45.56 | prpplague | solar: greetings |
| 14:45.58 | solar | prpplague: made good progress yesterday. ds2 is using for his carrier with the eabi userland on the hammer. I also did a reflash of the nail using eabi. Afrer a few bumps. All is good. |
| 14:46.26 | prpplague | solar: ah lovely, so you have eabi working properly with the s3c24xx stuff then? |
| 14:46.40 | solar | yep. |
| 14:47.28 | solar | I can't flash the full image that I'm targeting for you on the nail however as the firmware image is 25M(stripped) |
| 14:48.01 | prpplague | solar: ahh |
| 14:48.19 | *** join/#edev CosmicPenguin (n=nobody@163.181.251.103) |
| 14:48.19 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 14:48.28 | prpplague | *cough* if someone hadn't forgotten to pack it, you could have used a sd card |
| 14:51.36 | solar | I do have a hammer carrier that has a SD slot. |
| 14:52.09 | solar | but don't have the openocd files for the hammer. Got them for the nail but I'm guessing they may differ a little |
| 14:53.01 | solar | or same process. Plug the flyswatter in place of the nail to the main comp. plug flyswatter into top of hammer chip. flashit over usb? |
| 15:02.53 | prpplague | solar: the hammer/nail opencd files are the same |
| 15:03.29 | prpplague | solar: the nail is nothing more than the flyswatter and the carrier board combined into a small package |
| 15:04.20 | solar | right. But to flash to SD vs the onboard flash? Any small changes |
| 15:04.56 | prpplague | solar: naw, don't flash to the sd, just use a sd card reader and setup the fs on the sd |
| 15:04.57 | solar | cuz it's not as easy as slapping a kernel on the SSD + jffs2.loop file I'm sure |
| 15:05.12 | prpplague | solar: super easy to use ext2 on the sd card |
| 15:06.04 | solar | you mean. Put base firmware that just does the loop mounting of the userland files on the onboard flash? Then make it do something like a pviot_root ? |
| 15:07.46 | solar | actually nevermind I need to get ready to jump in the shower in a few mins and I'm not anywere near anything alike awake yet. |
| 15:10.02 | prpplague | solar: np |
| 15:36.59 | *** join/#edev Ian_Daniher (n=it@204.10.219.119) |
| 15:43.02 | *** join/#edev Ian_Daniher (n=it@69.61.230.246) |
| 15:43.24 | prpplague | hmm, just got a call from a head hunter |
| 15:44.33 | CosmicPenguin | These things happen |
| 15:51.22 | prpplague | i'm considering going home for lunch and calling this guy back |
| 15:52.56 | *** join/#edev davidc__ (n=davidc__@S01060002b360aacd.vc.shawcable.net) |
| 15:53.07 | prpplague | davidc__: hey hey stranger |
| 15:54.14 | davidc__ | heya prpplague |
| 15:54.16 | davidc__ | prpplague - I'm back to civilization now |
| 15:54.30 | prpplague | davidc__: i thought you lived in canada? |
| 15:54.36 | prpplague | jokes with davidc__ |
| 15:54.57 | davidc__ | hah hah |
| 15:55.06 | *** join/#edev archaepteryx (n=snewman@69-12-128-195.dsl.static.sonic.net) |
| 15:55.07 | davidc__ | prpplague - still working on the hammer board? |
| 15:55.23 | prpplague | here and there, trying to pull a handheld project out of the fire |
| 15:56.28 | *** join/#edev Ei5GTB_ (n=Paul@78.16.228.160) |
| 16:10.50 | prpplague | heads to lunch |
| 16:44.02 | prpplague | returns |
| 16:47.03 | ds2 | morning |
| 16:47.20 | prpplague | ds2: greetings |
| 16:47.30 | prpplague | ds2: how do you stand on your demo? |
| 16:48.19 | ds2 | prpplague: much better now after getting very PO'ed at the hammer docs. got the bluetooth half done |
| 16:48.42 | ds2 | prpplague: the elinux.org docs on the hammer is worse then a mine field! |
| 16:48.44 | prpplague | ds2: what hammer docs are a problem? |
| 16:48.49 | prpplague | ds2: oh? |
| 16:49.08 | prpplague | ds2: do tell |
| 16:49.11 | ds2 | prpplague: 1. would be nice to indicate that the EINTxx lines map to GPIO Gxx |
| 16:49.21 | ds2 | 2. Buttons on the OTHER gpio lines does not work |
| 16:49.52 | ds2 | 3. The OpenOCD tarball on there does NOT work with the provided hammer.ocd/hammer.cfg files on the exact same page |
| 16:50.17 | ds2 | 4. The PDF on how to build openocd with the ftdi stuff has critical typos |
| 16:50.48 | ds2 | 5. It should be mentioned (if it is really the case), that Xmodem on busybox is total garbage |
| 16:50.59 | prpplague | hmm, first i've heard of any of these issues |
| 16:51.20 | ds2 | probally cuz I am the first/only user that doesn't have the CD so I am relying entirely on the elinux.org page |
| 16:51.42 | ds2 | (1) is cuz I need to map my button to the right info in the mact-tct file |
| 16:51.42 | prpplague | ds2: why didn't you download the ISO? |
| 16:51.52 | ds2 | prpplague: there is an ISO downloadable?!??!??? |
| 16:52.09 | ds2 | I would have if I can find it =) |
| 16:52.23 | ds2 | all those problems blew about 16 hours this weekend |
| 16:52.24 | prpplague | ds2: yea, should be listed on the wiki |
| 16:52.34 | prpplague | http://www.tincantools/prpplague |
| 16:53.10 | prpplague | 1) the main page for the hammer lists the primary and alternate functions for all the pins available |
| 16:53.27 | prpplague | 2) you can use a gpio for a button, you just have to turn on polling framework |
| 16:53.52 | ds2 | prpplague: it does not list the GPIO name for the EINT pins in the main hammer page |
| 16:54.17 | ds2 | I had to go find the samsung docs from a 3rd part (can't get them direct as samsung wants you to register, get approved, etc before they will give you that) |
| 16:55.03 | ds2 | point 2 is a fair answer... if had known about it... :) |
| 16:55.04 | prpplague | 3) looks like there was a mistake on labeling, the hammer.ocd and hammer.cfg on the wiki are for the newier openocd |
| 16:55.15 | prpplague | ds2: indeed you are rgiht, the eint's aren't listed properly |
| 16:55.33 | prpplague | ds2: the samsung docs are available on the wiki |
| 16:56.16 | prpplague | ds2: good feedback, i'll make the corrections |
| 16:56.48 | ds2 | ah, should've looked under s3c2410 instead of just underhammer |
| 16:57.27 | ds2 | donno how common x86_64 is but the posted ftdi stuff is 32 bits only |
| 16:58.10 | prpplague | ds2: what typo's did you find on the openocd build docs? |
| 16:58.20 | ds2 | it got to the point where I decided if things don't start working by the end of today, I was ready to duct tape in a gumstix (very ugly and other problems) |
| 16:58.57 | prpplague | ds2: sorry to hear that |
| 16:59.11 | ds2 | prpplague: Win_d_Types.h does not exists, it seems to work fine if I used WinTypes.h |
| 16:59.21 | prpplague | ds2: thats the kind of feedback i would have liked to have gotten ages ago |
| 16:59.41 | prpplague | ds2: what doc were you using? |
| 16:59.45 | ds2 | prpplague: heh... didn't have time to mess with it a while ago |
| 17:00.03 | prpplague | ds2: sorry, i meant from the early testers |
| 17:00.04 | ds2 | "How to Install OpenOCD for the Flyswatter.pdf"; I think it was from the tct site that I found it |
| 17:00.18 | prpplague | ds2: oh, i have no clue about that one |
| 17:00.20 | prpplague | looks |
| 17:00.49 | ds2 | prpplague: the cp commands show in the bold/monospaced fonts do not make sense; it is pretty much "cp FOO" |
| 17:01.23 | ds2 | doing the tar commands as shown is likely to result in a big mess since neither openocd nor libfdx2xx extact to their own directories |
| 17:02.04 | prpplague | ds2: i don;t believe i've ever seen the doc you are refering to |
| 17:02.09 | *** join/#edev archaepteryx (n=snewman@207.47.42.130.static.nextweb.net) |
| 17:02.23 | prpplague | ds2: the boss must have written it up |
| 17:02.39 | prpplague | yea |
| 17:02.46 | prpplague | prints a copy to redline |
| 17:02.53 | ds2 | prpplague: oh... it was about 9:00 (4 hours into trying to get a simple image onto the hammer) that I started to look at the flyswatter option |
| 17:03.20 | *** join/#edev bbradley (n=bbradley@78-105-167-16.zone3.bethere.co.uk) |
| 17:03.22 | prpplague | ds2: what problems did you have trying to upload an image to apex? |
| 17:03.27 | ds2 | so it was not helping that it started a new adventure into getting openocd |
| 17:03.42 | ds2 | prpplague: well, xmodem/apex does NOT like uploads of > 2M, apparently |
| 17:03.59 | ds2 | so I manually made a JFFS2 partition and started uploading tarballs in bits and peices |
| 17:04.35 | ds2 | after chopping up things and encasing each peice if a gzip header (this was the 4th time uploading), I had it all on there. But then JFFS2 blows up |
| 17:05.01 | ds2 | I suspect there is a patch needed for JFFS2 or mtd that is missing; but that's an adventure for another time |
| 17:05.03 | prpplague | ds2: i regularly upload 20+ files with no problems |
| 17:05.25 | ds2 | prplague: in apex or with the busybox rx? |
| 17:05.27 | prpplague | ds2: something doesn't sound right |
| 17:05.31 | prpplague | ds2: both |
| 17:05.59 | ds2 | the rx stuff seems to work fine if: 1. the file is under about 512K and 2. it is uploaded to a ramdisk |
| 17:06.16 | *** join/#edev Redhatter (n=vk4msl@2001:388:f000:0:0:0:0:279) |
| 17:06.21 | ds2 | violating either results in hangs, lock ups due to out of memory conditions, or random aborts |
| 17:07.04 | ds2 | the gzip encasement is to work around xmodem's know issue with appending data at the end; that causes problems when one is uploading chunks of a larger file bit at a time |
| 17:07.06 | prpplague | ds2: sounds like a block size issue |
| 17:07.25 | prpplague | ds2: i'm guessing your pc side client was auto adjusting the block size |
| 17:07.28 | ds2 | could be, but I tried the 1K and the stock options with the sx command |
| 17:07.40 | ds2 | prpplague: I am using the Linux sx/sz/sb stuff |
| 17:08.08 | prpplague | ds2: yea, depending on what options it was compiled with it can do that |
| 17:08.36 | ds2 | what I am guessing is bb rx buffers everything in memory and when it tries to write out to jffs2, that causes large drops in the serial port end |
| 17:08.40 | prpplague | ds2: well when you get done with your demo, i'd love to iron out some of these details |
| 17:08.48 | ds2 | could be. |
| 17:08.58 | prpplague | ds2: yea, plus writing to flash is much slower too |
| 17:09.34 | ds2 | don't mind doing that but at the moment, the hammer is the most painful platform I have used to date. the webpals were nicer despite some issues with trigger the gdb connect |
| 17:10.53 | prpplague | ds2: very interesting |
| 17:11.11 | prpplague | ds2: guess that's why they haven't been selling |
| 17:11.21 | ds2 | prpplague: maybe I been spoiled by the omaps |
| 17:11.47 | ds2 | even back when there were no docs (pre beagle era), they seem to mostly do the right thing |
| 17:12.00 | prpplague | ds2: i'm just jaded, so i think everything is there when it isn't for alot of people |
| 17:12.16 | adyer | ds2 my experience has been that sx/sb/sz is very touchy |
| 17:12.22 | prpplague | ds2: what other items to you find difficult with the hammer? |
| 17:14.09 | ds2 | prpplague: the default ramdisk setup is a pain. it should have more hooks so one doesn't have go rebuild the flash image and reflash it... i.e the rc scripts could check for /mnt/flash/rc.user |
| 17:14.19 | ds2 | prpplague: but thanks to Solar, that wasn't too much of an issue |
| 17:14.44 | prpplague | ds2: interesting |
| 17:14.56 | ds2 | adyer: interesting. sz worked prefectly for me before... this is my first major use of sx; otherboards use kermit and that's a slew of "stuff" to configure |
| 17:14.58 | prpplague | ds2: to me that kind of defeats the purpose of getting the device |
| 17:15.12 | prpplague | ds2: if all you are going to do is use the stock image |
| 17:15.47 | ds2 | prpplague: the default ramdisk is nice for a demo but I want to be able to do stuff with it right away and I am happy to drop in binaries into /mnt/flash, write a script and be done with |
| 17:16.04 | ds2 | prpplague: well, keep in mind, I am a kernel centric person and userland is almost an afterthought. |
| 17:16.40 | ds2 | all I really needed to do was: take a stock hammer, drop in bluez + pppd, write a shell script to kick off rfcomm + pppd and I am done |
| 17:16.51 | ds2 | it _SHOULD_ have been no more then a 30 minute exercise |
| 17:17.05 | ds2 | sure, I replaced the kernel |
| 17:18.08 | ds2 | and it WAS a 30minute exercise with the gumstix |
| 17:18.20 | prpplague | ds2: i agree that it should have been 30 minutes, just not sure why it too you so long |
| 17:18.37 | *** join/#edev kergoth (n=kergoth@ip72-201-11-30.ph.ph.cox.net) |
| 17:18.49 | ds2 | prpplague: the adventure was having to replace the rootfs |
| 17:19.05 | prpplague | ds2: i don't understand why that is a problem |
| 17:19.14 | ds2 | that lead to figure out openocd (first time I _had_ to use openocd to do this) |
| 17:19.16 | prpplague | ds2: you should have been able to build a new one in 20 minutes |
| 17:19.34 | ds2 | prpplague: building is not really an issue here; solar built one for me |
| 17:19.40 | ds2 | it is getting it onto there! |
| 17:20.28 | ds2 | on other boards, I am used to being about to - mount /dev/mtdblk0, untar it onto the mount point, reboot; change boot argments, and I am done |
| 17:20.50 | prpplague | ds2: you could do the same with the hammer |
| 17:21.01 | ds2 | prpplague: that's where the xmodem issues came into play |
| 17:21.16 | ds2 | xmodem 100+ times over a serial link eats a lot of time |
| 17:22.23 | prpplague | ds2: something doesn't sound right, i'm guessing you had some noise or something on your uart |
| 17:22.59 | ds2 | the full tarball of the rootfs is 5M, that failed, chop it that up into 3 tarballs, that failed, chop up the tarballs, find that xmodem appends garbage, repeat, find jffs2 corrupted, start all over |
| 17:23.01 | prpplague | ds2: i just uploaded a 11mb file via the uart with no problems |
| 17:23.25 | ds2 | prpplague: is your uart wired up for hardware flowcontrol? |
| 17:23.34 | ds2 | I am using a 3wire setup |
| 17:23.35 | prpplague | ds2: the garbage is normal with busybox rx |
| 17:23.46 | prpplague | ds2: yea three wire setup |
| 17:23.52 | prpplague | ds2: same as on the carrier board |
| 17:24.00 | ds2 | hmmm odd |
| 17:24.23 | prpplague | ds2: busybox's rx doesn't handle partial block writes |
| 17:24.26 | ds2 | I do have 12" of untwisted wiring but the overcall cable is <6ft |
| 17:24.40 | prpplague | ds2: so when the transfer ends it writes out 1 complete block, garbage and all |
| 17:25.29 | prpplague | ds2: most other packages with calculate the actual partial block and clean it up before writing |
| 17:25.32 | ds2 | prpplague: that's common with xmodem; should have known the garbage part but it has been >10years since I really used xmodem (BBS's, most of them used zmodem to avoid this) |
| 17:26.01 | prpplague | ds2: were you using buildroot to generate your images? |
| 17:26.25 | ds2 | prpplague: no, solar used gentoo and built it |
| 17:26.43 | prpplague | ds2: OH |
| 17:26.59 | ds2 | I was not about to step into the buildroot issues given my time constraints; it would either be me untarring binaries and rewriting the JFFS2 image or some other hackery |
| 17:27.32 | prpplague | ds2: interesting |
| 17:27.38 | ds2 | past gumstix experience suggests, I should budget about 8hours to get build root running right |
| 17:28.20 | prpplague | ds2: on an average box you should be able to have the hammer buildroot complete in about 20-30 minutes |
| 17:28.41 | ds2 | prpplague: half that time is clearing out enough disk space :( |
| 17:29.07 | prpplague | checks the size of a current build |
| 17:29.13 | ds2 | a single run is not bad, but getting it running right and doing what you want takes some setup time |
| 17:29.21 | ds2 | I think it should be around 1G or so |
| 17:30.16 | prpplague | the hammer buildroot is pretty darn stable |
| 17:30.39 | prpplague | ds2: yea i have a pretty large build, its 1.25G |
| 17:30.41 | ds2 | the fun comes when you want it to do something slightly different |
| 17:31.18 | prpplague | ds2: well for what you described you should have been able to just select the option you wanted in the menu and just do make |
| 17:32.02 | ds2 | prpplague: maybe you have worked out the bugs, but on the gumstix, enabling new packages is always "interesting" |
| 17:32.33 | prpplague | ds2: the only package that hasn't been heavily tested is the kdrive stuff |
| 17:32.50 | ds2 | good to know |
| 17:33.02 | prpplague | ds2: the rest has been tested on ubuntu,debian, and fedora |
| 17:33.30 | ds2 | but the control that solar had with stripping things has me partially sold on the gentoo stuff |
| 17:34.12 | prpplague | ds2: stripping things? |
| 17:34.30 | *** join/#edev kergoth (n=kergoth@ip72-201-11-30.ph.ph.cox.net) |
| 17:34.53 | ds2 | prpplague: no, being able to exclude stuff... if I understand things right, libgcc_s.so was part of the gcc package; but it was possible to just include that binary and not the entire compiler |
| 17:34.58 | *** join/#edev Ei5GTB_ (n=Paul@78.16.171.55) |
| 17:35.39 | prpplague | ds2: all of that is possible with buildroot |
| 17:35.57 | prpplague | ds2: but i see where you are coming from on that |
| 17:36.24 | ds2 | I know about the little hooks to do similar things |
| 17:36.28 | ds2 | (in BR) |
| 17:36.45 | prpplague | ds2: i guess i can do a kitchen sink rootfs for people to play with |
| 17:37.04 | prpplague | ds2: i just would have thought people would want to use it that way |
| 17:37.10 | ds2 | prpplague: don't need that; just make it possible to have a persistant modification |
| 17:37.10 | prpplague | i certainly wouldn't |
| 17:37.43 | ds2 | say, if i want a $99 LED flasher w/o kicking off buildroot, I should be able to (drop in a script into flash and be done with) |
| 17:38.14 | ds2 | if all it did was had a call to /mnt/flash/rc.user, I would be happy |
| 17:38.26 | prpplague | ds2: that makes no sense to me at all, but i can do thta |
| 17:38.41 | ds2 | prpplague: or make it so the default rootfs is on flash |
| 17:38.52 | ds2 | but that's apotential support nightmare |
| 17:39.24 | ds2 | right now I am happy having the default initrd AND rootfs on flash |
| 17:39.52 | ds2 | screwup flash rootfs; I can go into a shell in the initrd with a command line change |
| 17:40.54 | *** join/#edev eut (n=keram@Macaw.cens.UCLA.EDU) |
| 17:40.58 | ds2 | but, I donno how much I match your typical user. |
| 17:40.59 | prpplague | ds2: hmm well, definetly something to think about, as i said, i certainly wouldn't have approached it like that |
| 17:41.26 | prpplague | ds2: i can see how people from arduino area would want that ease of usage |
| 17:41.28 | ds2 | prpplague: you do things to make it reproduceable/manufactureable; I am doing a one off |
| 17:41.30 | prpplague | eut: greetings |
| 17:41.58 | eut | prpplague, hello |
| 17:42.03 | prpplague | ds2: indeed, but i can see how people would think similiar to what you recommended |
| 17:42.29 | prpplague | ds2: question, why didn't you use a usb thumbdrive to transfer the image over? |
| 17:43.09 | ds2 | prpplague: cuz I was afraid of cracking the capacitors on the end of the board if I had to move it back to the hammer carrier |
| 17:43.38 | prpplague | ds2: i thought you had a usb slave port on the board you made |
| 17:44.19 | ds2 | prpplague: I suppose I could have done that but my board had no power control |
| 17:44.42 | ds2 | donno how safe it is to hotswap such a setup |
| 17:45.03 | prpplague | ds2: its pretty safe, just not spec |
| 17:45.08 | ds2 | but I suppose that would have been a workaround |
| 17:45.27 | prpplague | ds2: well, i'll do some work on the defaul image, and you can give it a try if/when you have time |
| 17:45.52 | ds2 | sure |
| 17:47.04 | ds2 | I donno how many know enough to get them in trouble with this but it might be nice to mention somewhere that the default stuff on the hammer is OABI but the openmoko stuff is EABI |
| 17:47.38 | ds2 | didn't cost too much time there but it was a bit puzzling til solar mention that little detail then it became obvious |
| 17:48.10 | ds2 | (yes, I was unpacking most of the openmoko stuff into flash and chrooting to attempt to run it) |
| 17:48.24 | ds2 | s/most/enough to do what i want/ |
| 17:48.50 | solar | would be happy to show ds2 how I do it. |
| 17:49.55 | ds2 | solar: another time. But I am very interested in trying to get a gentoo setup going; not just for the hammer but for other stuff |
| 17:50.20 | ds2 | it does seems like a logical next step up from what I normally do (hand assemble then write a shell script) |
| 17:50.42 | ds2 | BR/OE is further away from what I want/like |
| 17:51.14 | *** join/#edev pea (n=pea@75.58.4.163) |
| 17:52.10 | prpplague | ds2: we;;, this is a new direction for development for me, i pretty much always build from scratch |
| 17:52.23 | prpplague | ds2: we'll i mean |
| 17:52.38 | ds2 | after this is done, I might update the howto page for adding an LED... there is some minor quirks that others might be able to use and not have to debug |
| 17:53.07 | prpplague | ds2: such as? |
| 17:53.28 | ds2 | prpplague: like what needs to be unique when defining multiple LEDs |
| 17:53.56 | ds2 | there are 2 things that _appear_ to need to change, but only one of them should otherwise, it breaks ;) |
| 17:54.39 | ds2 | one entry is the name of the driver to attach, the other is the id of the LED; I don't think the examples point out that detail |
| 17:54.41 | prpplague | ds2: uh, what two things? i only see one |
| 17:55.08 | prpplague | ds2: hmm, i would think that is obvious, but i guess not |
| 17:55.41 | ds2 | s3c24xx_led for the name field and the id |
| 17:56.16 | ds2 | name w/o any context suggests it may be an arbitrary string that needs to be unique for all the LEDs |
| 17:56.47 | ds2 | I actually changed them to s3c24xx_led[012] then realize that is the driver to attach to(!) |
| 17:57.05 | prpplague | ds2: there are several other examples on the page where that doesn't change, but i see your point |
| 17:57.16 | prpplague | ds2: again, i'm too jaded with this type of information |
| 17:57.26 | ds2 | it was semi-obvious once I looked at what happened |
| 17:57.45 | prpplague | well i'm making a long list of stuff to update |
| 17:57.57 | prpplague | i wish i had more people giving this type of feedback |
| 17:58.24 | ds2 | if you are used to platform drivers (coming from the ARM/embedded world, you are), but if you are used to x86 where the buses probe and stuff... that name member might not be that meaningful |
| 17:58.42 | ds2 | I really should have known better but haste makes waste |
| 17:59.09 | prpplague | well this does fit in with what i've been hearing/seeing with the arduino stuff |
| 17:59.34 | prpplague | most of these folks don't want to tinker with a bunch of the stuff, they just want "tweak" it a little for their application |
| 17:59.42 | ds2 | that's interesting... I been mostly ignore those things |
| 17:59.59 | ds2 | I do it this way for demos since it is a one off |
| 18:00.30 | prpplague | ds2: as was i, but i've found there is some concepts that make it extremely attractive to hobbists and developers alike |
| 18:02.03 | ds2 | the plus side for the hammer is it appears all the GPIO's are already defined in the headers |
| 18:02.44 | ds2 | the omaps don't have all the GPIOs listed so one has go in and edit the relevant pin mux stuff to mess with the GPIOs |
| 18:04.36 | prpplague | yea |
| 18:04.43 | *** join/#edev Ian_Daniher (n=it@69.61.230.246) |
| 18:05.11 | ds2 | btw, am I the first person to be running BT on the hammer? |
| 18:06.20 | prpplague | ds2: i have, just never posted anything |
| 18:07.08 | ds2 | what profiles? |
| 18:07.08 | prpplague | http://www.elinux.org/Hammer_Bluetooth |
| 18:07.30 | prpplague | ds2: just using rfcomm |
| 18:07.56 | prpplague | ds2: without dbus and the other works |
| 18:08.08 | ds2 | I mean what did you connect to |
| 18:09.01 | prpplague | ds2: barcode scanner, some sparkfun modules, and a pc |
| 18:09.02 | ds2 | prpplague: I think Ihave a conflicting report, I believe I have one of the "don't work" dongles working |
| 18:09.22 | prpplague | ds2: what kernel are you using? |
| 18:09.26 | ds2 | nice.. so I can claim I am the first to have it working with a phone and getting a WAN connection ;) |
| 18:09.33 | prpplague | ds2: there were a number of them on 2.6.22 that had issues |
| 18:09.40 | prpplague | ds2: yep |
| 18:09.41 | ds2 | 2.6.22 + hammer patches + my tweaks for gpio |
| 18:09.50 | prpplague | ds2: interesting |
| 18:10.25 | ds2 | the picture and packaging matches; don't have my invoice to verify the P/N |
| 18:11.44 | prpplague | one of the cyberblue units? |
| 18:11.59 | ds2 | http://www.geeks.com/details.asp?invtid=BLK-USBCYBERBLUE-BT&cpc=SCH |
| 18:12.01 | ds2 | yes |
| 18:12.50 | prpplague | ds2: yea, they swap out the actual electronics all the time for those, we felt it was better to mark them as bad , rather than people buy them and get mixed results |
| 18:12.57 | *** join/#edev magnetron (n=magnetro@unaffiliated/magnetron) |
| 18:13.00 | ds2 | ah |
| 18:13.22 | ds2 | usb 1-1: Product: ISSCEDRBTA |
| 18:13.22 | ds2 | usb 1-1: Manufacturer: ISSC |
| 18:13.27 | ds2 | that is the ID I see |
| 18:13.44 | prpplague | ds2: yea that is different that the cyberblue units i have |
| 18:15.04 | prpplague | ds2: well sorry i wasn't online to help, was feeling under the weather over the weekend\ |
| 18:15.25 | ds2 | prpplague: nah... it is cool |
| 18:17.26 | prpplague | has too many irons in the fire |
| 18:17.40 | ds2 | doesn't everyone |
| 18:18.09 | prpplague | ds2: yea, problem is when i get too many things going, nothing gets done |
| 18:18.19 | ds2 | =) |
| 18:26.46 | prpplague | ds2: still around? |
| 18:33.07 | ds2 | yes? |
| 18:33.50 | *** join/#edev corte1 (n=egoe@demolitionman.xs4all.nl) |
| 18:36.19 | *** join/#edev roxfan2 (n=dunno@137.13-200-80.adsl-dyn.isp.belgacom.be) |
| 18:36.27 | prpplague | ds2: nm, i'll catch you on it later, i know you are busy |
| 18:37.12 | ds2 | okay... just planning out the next steps right now before lunch |
| 18:38.55 | *** join/#edev DrZimmerman (n=theo@77-56-242-58.dclient.hispeed.ch) |
| 19:04.09 | *** join/#edev __martin_ (n=martin@netblock-68-183-167-49.dslextreme.com) |
| 19:04.53 | *** part/#edev adyer (n=adyer@adsl-69-223-13-78.dsl.chcgil.ameritech.net) |
| 19:11.46 | *** join/#edev landley (n=landley@static-71-162-243-5.phlapa.fios.verizon.net) |
| 19:11.47 | *** mode/#edev [+o landley] by ChanServ |
| 19:25.11 | *** join/#edev magnetron (n=magnetro@unaffiliated/magnetron) |
| 19:27.25 | prpplague | anyone here using the beagle board besides ds2 ? |
| 19:29.26 | prpplague | landley: greetings |
| 19:29.43 | landley | prplague: morning. |
| 19:45.17 | *** join/#edev RobotGuy (i=d047c850@gateway/web/ajax/mibbit.com/x-0e57326ab8fe2e51) |
| 19:45.23 | *** join/#edev kergoth (n=kergoth@65.200.49.156) |
| 19:46.14 | *** join/#edev kergoth (n=kergoth@65.200.49.156) |
| 19:46.15 | *** join/#edev likewise (n=likewise@82-171-51-231.ip.telfort.nl) |
| 19:54.36 | *** join/#edev roxfan2 (n=dunno@137.13-200-80.adsl-dyn.isp.belgacom.be) |
| 20:02.25 | *** join/#edev RobotGuy (i=d047c850@gateway/web/ajax/mibbit.com/x-db8a11dec315a1cb) |
| 20:54.00 | MothaWork | prpplague: how complicated is the flyswatter and other jtag devices? They seem fairly straightforward if you don't need isolation and know your target voltage levels |
| 20:54.33 | prpplague | MonMotha: yea the ft2232 has a builtin jtag controller, which makes it pretty simple |
| 20:54.35 | MothaWork | For our next device, we're thinking of having a dedicated "development" (and programming, etc.) port to which a test/debug fixture would be attached, and if it's simple, I might as well just drop the JTAG right on that |
| 20:54.43 | prpplague | MonMotha: the flyswatter schematic is posted on the website |
| 20:54.43 | MothaWork | excellent, then |
| 20:55.20 | __martin_ | Hi! I asked this in #elinux, but it was suggested I ask the same thing here the other day. I am looking for a pxa27* or pxa23* (or equiv.) SBC with either a PCMCIA slot or a minipci slot that runs < 1W or < 2W. There are some more specs but these are the most cruicial. We've found one at www.compulab.co.il that may work... but we are still looking. |
| 20:55.43 | MothaWork | __martin_: check embeddedarm.com |
| 20:55.48 | mnemoc | :) |
| 20:55.49 | MothaWork | they have things like that, but I'm unsure of their power requirements |
| 20:56.50 | __martin_ | How does the arm9 compare to the pxa27* or pxa30*? |
| 20:57.13 | MothaWork | depends on what you're doing and which ARM9 you have |
| 20:57.34 | prpplague | __martin_: at the core of it is the number stages in the processing pipe |
| 20:57.47 | __martin_ | Our software is pretty heaty... it ran fairly well on a pxa255... |
| 20:58.02 | prpplague | http://www.elinux.org/ARM_Processor |
| 20:58.38 | MothaWork | leaves work |
| 20:58.42 | prpplague | __martin_: xscale is a 8/9 stage pipe, whereas the arm9 series is a 5 stage pipe |
| 20:59.22 | prpplague | __martin_: the more stages in the pipe the higher the clock frequency you can have, but it comes with a tradeoff, it takes more time to properly fill the pipe |
| 21:00.10 | __martin_ | prpplague: so like some high Mhz Pentium 4's were just as fast as some of the lower Pentium M's out there (at least in my experience sitting behind computers with each of those)? |
| 21:00.28 | prpplague | __martin_: in some cases yes? |
| 21:00.49 | ds2 | heh |
| 21:00.53 | __martin_ | prpplague: so basically I have to get one to test it |
| 21:01.36 | prpplague | __martin_: probably, imho |
| 21:01.45 | ds2 | I'd think it also depends on which ARM9 |
| 21:01.57 | ds2 | an arm920 is very different from say an arm926 |
| 21:02.09 | prpplague | ds2: indeed |
| 21:02.11 | __martin_ | so like the 500Mhz ARM9 in MothaWork's embeddedarm.com link? |
| 21:03.06 | __martin_ | that could potentially be comparable to the pxa25* or pxa27*? |
| 21:03.46 | prpplague | yep |
| 21:05.33 | ds2 | donno about that |
| 21:05.45 | ds2 | they are CL ARM9's those appear to be 920's |
| 21:09.18 | prpplague | ds2: if they are the same frequency, you actually get slightly better performance from the arm920 |
| 21:10.05 | ds2 | whoa |
| 21:10.29 | ds2 | so does that mean if I clock a StrongARM at the same speed as a PXA, the SA would win? |
| 21:10.36 | MonMotha | ds2: likely |
| 21:10.45 | MonMotha | good luck doing so |
| 21:10.56 | MonMotha | the PXAs usually do have more cache, though |
| 21:10.56 | ds2 | holy crap, I didn't know Intel did that big of a butcher job |
| 21:11.32 | MonMotha | if you can keep the pipeline full, then it's all about IPC (which usually doesn't go much higher than 1 on ARM, except perhaps the really new stuff) |
| 21:11.43 | MonMotha | but with a longer pipeline, it's harder to keep it full |
| 21:11.50 | MonMotha | that's what killed the P4 |
| 21:12.06 | MonMotha | 37 stage pipeline, IIRC |
| 21:12.18 | MonMotha | hell, that thing had multiple clock domains |
| 21:13.04 | ds2 | hmmm |
| 21:14.22 | prpplague | and generally with higher clock counts, the more power you are using |
| 21:14.37 | MonMotha | indeed |
| 21:14.46 | MonMotha | yet another thing that killed the P4 |
| 21:14.58 | MonMotha | P ~ V^2*f |
| 21:14.59 | prpplague | problem is that most people are used to x86 measurements where "higher process clocking" is the measure of performance |
| 21:15.17 | MonMotha | prpplague: indeed |
| 21:15.25 | MonMotha | for some real fun, play around with a 1GHz DSP some tim |
| 21:15.37 | MonMotha | there are DSPs can can retire 4+ instructions in a cycle |
| 21:16.02 | MonMotha | some of those 1GHz DSPs can achieve ~2GMAC/sec |
| 21:18.07 | prpplague | ds2: an arm920t running at 200MHz is about the same performance as a xscale running at 280MHz |
| 21:24.10 | ds2 | HMmm |
| 21:24.52 | ds2 | prpplague: now, what about the same two cores in the power dimension, that is...what's the relative power draw of the 920t vs the xscale |
| 21:25.31 | prpplague | ds2: running at the same frequency they are about the same |
| 21:25.52 | prpplague | with the xscale being slightly high due to the larger pipe |
| 21:25.56 | prpplague | with the xscale being slightly high due to the larger pipe |
| 21:25.59 | ds2 | so the processing power per watt goes down |
| 21:26.39 | prpplague | ds2: yea, the theory is do more in one clock to keep the number of clocks nessary to a minimum |
| 21:26.56 | prpplague | ds2: which is the whole basis of ARM cores |
| 21:28.31 | *** join/#edev CosmicPenguin (n=nobody@163.181.251.103) |
| 21:28.31 | *** mode/#edev [+o CosmicPenguin] by ChanServ |
| 21:34.36 | ds2 | this nice, a dollar store USB cable is cheaper then buy a USB A plug |
| 21:35.35 | prpplague | hehe |
| 21:36.10 | *** join/#edev Ian_Daniher (n=it@69.61.230.246) |
| 21:36.47 | ds2 | I need a quick power cable for the hammer carrier so one dollar store USB cable and a ~$0.50 power jack + 5mins later and I have it |
| 21:39.08 | ds2 | it is nice the beagle takes the same power as the hammer carrier |
| 21:39.46 | likewise | how do you guys deal with bidirectional reset pins and FlashROM reset? |
| 21:40.03 | likewise | I see many designs where a watchdog reset would not reset the FlashROM properly. |
| 21:40.22 | likewise | NOR FlashROM that is. |
| 21:40.25 | ds2 | some flashroms have a reset input |
| 21:40.43 | ds2 | but I have seen the problem where the NOR is stuck in command mode |
| 21:40.57 | likewise | yes, and most hardware designers do not tie it to the birectional reset pin..., only to the power up reset |
| 21:41.18 | likewise | ds2: indeed, that's the exact problem I mean. |
| 21:41.36 | likewise | so what's a proper reset circuitry design for that. |
| 21:41.42 | ds2 | likewise: that occurs on some $$$$$$$$$$ development board |
| 21:42.07 | likewise | I even know processors (XScale IXP4xx) that cannot even do reset the FlashROM on a watchdog reset.... |
| 21:42.30 | ds2 | the companion chip is suppose to do it |
| 21:42.39 | likewise | so the question is very valid, but I'm looking for a good solution. |
| 21:43.11 | ds2 | unfortunately, I don't have a solution to describe; just a confirmation that the problem is wide spread |
| 21:43.16 | ds2 | and it isn't just watchdog |
| 21:43.36 | ds2 | it can happen if you wire up a reset button and route it through the companion chip |
| 21:47.18 | *** join/#edev roxfan2 (n=dunno@137.13-200-80.adsl-dyn.isp.belgacom.be) |
| 22:09.27 | *** join/#edev dijenerate (n=dijenera@65.48.164.209) |
| 22:11.27 | *** join/#edev roxfan (n=dunno@137.13-200-80.adsl-dyn.isp.belgacom.be) |
| 22:16.52 | *** join/#edev redblue (i=star@ppp227.108-253-207.mtl.mt.videotron.ca) |
| 22:18.56 | *** join/#edev dijenerate (n=dijenera@65.48.164.209) |
| 22:34.15 | *** part/#edev archaepteryx (n=snewman@207.47.42.130.static.nextweb.net) |
| 23:06.16 | __martin_ | Well... thanks for all the input everyone! I may come back and ask again.. maybe there are others that have seen the type of board I would like. |
| 23:06.20 | __martin_ | bye! |
| 23:16.47 | ds2 | Hmmmm odd behavior on the serial ports or getty |
| 23:20.10 | ds2 | interesting... 115200 over 12" of wire is having problems |
| 23:32.02 | MonMotha | ds2: but it works at slower speeds? |
| 23:41.55 | ds2 | MonMotha: at 115200, I loose every other packet (PPP over an RS-232 cable) |
| 23:42.04 | ds2 | at 38400, I get 0 loss |
| 23:42.49 | MonMotha | I'd say either your cable or level shifters suck |
| 23:43.09 | MonMotha | and it's lose, btw |
| 23:43.14 | MonMotha | (pet peeve of mine) |
| 23:44.04 | ds2 | well, YOU decide - cable is essentially 3 (GND, TXD, RXD) clipleads, 12" long; level shifters are a 1.8V to 3.3V on each line using a pair of open drain inverters :) |
| 23:44.10 | ds2 | which sucks more? ;) |
| 23:45.00 | MonMotha | you're trying to run open drain outputs into cabling? |
| 23:45.08 | MonMotha | hope you have a STRONG pullup |
| 23:45.28 | ds2 | yes, I am but these are between 2 boards that are close; they are physically within an inch of each other |
| 23:45.32 | MonMotha | anything over several inches tends to start to cause problems |
| 23:45.41 | ds2 | I am making up some 5" long cables |
| 23:45.45 | MonMotha | depends on the strength of the pullup, of course |
| 23:45.50 | MonMotha | got a scope? |
| 23:46.16 | ds2 | sure |
| 23:46.32 | MonMotha | use it :) |
| 23:47.16 | ds2 | it works at 38400, that's good enough |
| 23:48.00 | ds2 | too many other things that needs to be done for this one off |
| 23:49.27 | solar | such a busy day today. |
| 23:49.35 | solar | ds2: make good progress? |
| 23:49.54 | ds2 | anyone know off hand what the telnetd in busy box looks for as far as pty's? /dev/ptyXX or /dev/pts/X? |
| 23:50.11 | solar | you need a /dev/pts/ for telnetd or dropbear |
| 23:50.31 | ds2 | solar: yep. got the 2 boards talking; bluetooth connects to the phone on button push...just need to do the slidesshow and have it drive some LEDs on events and I am done |
| 23:50.40 | ds2 | ah no wonder... I was setting up bsd pty's |
| 23:50.56 | solar | was that using that hammer userland I passed over to ya? |
| 23:51.00 | ds2 | yep |
| 23:51.21 | solar | and this is what you will be using for your demo at the MV embedded show in sfo? |
| 23:51.29 | ds2 | that userland is working very well, only quirk was when changing speed of a getty |
| 23:51.34 | ds2 | yep |
| 23:51.40 | ds2 | solar: you showing up there? |
| 23:51.41 | solar | does a happy dance then |
| 23:52.04 | ds2 | but the speed change might be a s3c2410 thing |
| 23:52.16 | solar | I can probably arrange it. Depends if I have to pay to get in or can find another route. |
| 23:52.33 | solar | is it a pay-per-entry kinda show?? |
| 23:52.48 | ds2 | on paper, yeah |
| 23:55.21 | solar | dunno. I have mixed feelings about MV. They do some really cool stuff. Seem to be behind most of the porting of new arm devices. But some things seemed down right archaic |
| 23:55.58 | ds2 | it is a convoluted world |
| 23:56.05 | solar | you used to work for MV right? |
| 23:56.10 | ds2 | *nod* |
| 23:56.39 | solar | solo/contractor role now? |
| 23:56.47 | ds2 | yep |
| 23:56.53 | solar | working out ok? |
| 23:57.09 | ds2 | donno, ask me in 6months... the changes are relatively recent |
| 23:57.14 | solar | cuz this town is.. yikes spendy. I'd be afraid to try and go solo here. |
| 23:57.26 | ds2 | I know what you mean |
| 23:57.41 | solar | but if one does. Oh my. The reward would probably be well worth the risk |
| 23:57.47 | ds2 | and there ain't much room under the few bridges they do have |
| 23:58.57 | ds2 | but at least the card board boxes around here are relatively clean |
| 23:59.18 | solar | the company I'm working with started out with 15k capitol. Grown into a little almost 2mill a month in MRR in 6 years |
| 23:59.45 | ds2 | but they go down hill just as quickly |