| 00:00:02 | GoRK | SpaceCoaster: ok im bringing the revision 1.15 driver closer into sync with the one we replaced last night. what do you want me to version it? |
| 00:00:21 | GoRK | SpaceCoaster: i dont knwo what we were up to before |
| 00:00:36 | SpaceCoaster | GoRK: one moment... |
| 00:02:28 | SpaceCoaster | ok, the one that was sent with the 32M SODIMM support was 1.18, so if we make this 1.19 then that should reduce confusion. |
| 00:02:50 | SpaceCoaster | what have you put in? |
| 00:02:54 | GoRK | SpaceCoaster: good. i havent touched wheaties_write yet.. what is the thing with bits vs bytes |
| 00:03:37 | GoRK | SpaceCoaster: i just did all the changes that didn't affect xfer_byte (xfer_bits) or delays since that is undoubtadely where the problem lies |
| 00:04:28 | EGg0 | Anyone know if BZFlag has tuxscreens available before I set up PayPal? |
| 00:04:30 | SpaceCoaster | well the same code can be used for both the serial flash and the dsp, so the xfer_bits is a more general form of xfer_bytes, bits can do 1 through 32 bits. |
| 00:04:53 | GoRK | EGg0: he does |
| 00:04:59 | EGg0 | Thanks. |
| 00:05:05 | GoRK | EGg0: see the topic :) |
| 00:05:06 | SpaceCoaster | EGg0: I'm sure he has lots, he sells about 30 odd a week and had 700+ last week |
| 00:05:38 | EGg0 | GoRK: The topic is blank on my Xchat. |
| 00:05:49 | GoRK | hmm maybe the conversion fubar'd it |
| 00:05:55 | SpaceCoaster | hey GoRK we can set the top ourselves, no overlords on this channel. |
| 00:06:03 | SpaceCoaster | s/top/topic/ |
| 00:06:12 | GoRK | i know i didnt realize there was no topic |
| 00:06:31 | SpaceCoaster | GoRK: your go |
| 00:07:15 | GoRK | :) |
| 00:07:36 | GoRK | hmm my static variable doesnt seem to want to be static :-/ or the tuxphone network code broke it |
| 00:08:24 | GoRK | or maybe its glibc |
| 00:09:51 | SpaceCoaster | GoRK: if you look at spi.c that has the common code between wheaties and serial_flash, we can use that when serial_flash is ready for release. |
| 00:17:21 | EGg0 | GoRK: Okay, I see the topic. However, I did visit the site, saw that they were available "until he runs out," saw that he was BZFlag on this channel, saw that he was not around, so asked those who were. THat's why I asked. |
| 00:19:03 | SpaceCoaster | EGg0: It was a good idea to check before you send the money. |
| 00:27:07 | SpaceCoaster | EGg0: got any cool plans for your TuxScreen? |
| 00:28:19 | GoRK | eggo: i wasnt questioning why you asked |
| 00:28:38 | GoRK | SpaceCoaster: so spi.c doesnt do anything right now? |
| 00:28:38 | EGg0 | Hrm... Haven't thought too terribly much about it yet. I've got a nice Solar Panel and power converter I was planning on playing with, nothing more planned until I get Linux installed. |
| 00:29:03 | GoRK | SpaceCoaster: could the delays etc be causing the data corruption? |
| 00:30:57 | SpaceCoaster | GoRK: on the serial flash, I doubt it, the delays for the serial flash are all short and well documented, it is real SPI hardware on the serial flash. |
| 00:31:35 | SpaceCoaster | GoRK: as opposed to undocumented delays on the DSP, which I think implements the interface in software. |
| 00:32:28 | GoRK | so any testing i can do to help? |
| 00:35:04 | dirkx | Anyone familliar with the error |
| 00:35:04 | dirkx | entry-armv.S:832: Error: Internal_relocation (type 210) not fixed up (OFFSET_IMM) |
| 00:35:11 | dirkx | when cross compiling ? |
| 00:35:14 | SpaceCoaster | maybe, if you compile spi.c and serial_flash.c up as modules you should be able to load them. You can cat /proc/mtd (or something) to see the atmel devic. You can read/write /dev/mtdblock3 using dd in 8192 byte chunks. |
| 00:40:07 | GoRK | dirkx: i have seen it before but i dont remember what i did to fix it |
| 00:40:15 | dirkx | Linux experts: When crosscompiling the buildroot; should 'include/linux/autoconf.h' be generated by linux/scripts/Menuconfig automatically - or should I do this manually (Rigth now I am doing a simple 'make world' in the top level dir). |
| 00:40:53 | GoRK | afaik make world should be all you need to get a root image and kernel |
| 00:41:02 | dirkx | GorK: Thanks - I suspect it is related to some .h symbol file which is not properly generated. |
| 00:41:36 | dirkx | GoRK: - Hmm - it barfs on 'linux/include/linux/autoconf.h' not found. Something I can force by running this Menumaker. |
| 00:41:39 | GoRK | i dont think the problem is in buildroot-tux.... what compiler/toolchain are youusing? |
| 00:42:04 | dirkx | Plain arm versions of gcc/ld/as et.al. |
| 00:42:23 | GoRK | most of the folks here i believe are using the toolkit provided by the emdebian project.. gcc-2.95.2 |
| 00:42:56 | GoRK | they have .deb's and .rpm's up. it worked out of the box for me using that. people were having trouble with handhelds.org stuff |
| 00:43:18 | dirkx | Hmm - checking version... bash-2.05# arm-elf-gcc -v |
| 00:43:19 | dirkx | Reading specs from /usr/local/lib/gcc-lib/arm-elf/2.95.3/specs |
| 00:43:19 | dirkx | gcc version 2.95.3 20010315 (release) |
| 00:44:01 | dirkx | What versions of Linux does that run on ideally ? |
| 00:44:13 | GoRK | what? emdebian's stuff? |
| 00:44:36 | GoRK | any rpm distro or debian based distro really |
| 00:44:54 | GoRK | which is pretty much everything except slackware which afaik has rpm |
| 00:45:03 | GoRK | so even slackware could install it |
| 00:46:05 | prpplague | dirkx: i'm using the cross-compiler 2.95.3 pre-built by erikm, you can get it off rmk's web page or http://www.abcsinc.com/small-linux/binary.htmhttp://www.abcsinc.com/small-linux/binary.htm |
| 00:46:27 | prpplague | oops, didn't mean to do that twice |
| 00:46:32 | prpplague | http://www.abcsinc.com/small-linux/binary.htm |
| 00:46:46 | prpplague | little too jumpy, too much coffee |
| 00:46:55 | dirkx | Yes - RH version. Right now I am using a struct cross compile environment on BSD; but I've noticed that some of the path's in the Makefile are hardcoded to places like /sbin/genksyms and /sbin/depmod - which obviously are x86 rather than cross-compile arm based. So I am wondering if I need to make sure that the OS matches the target OS too. |
| 00:48:13 | GoRK | ah yeah if you're compiling on a BSD... well it's possible but you're going to be making some symlinks and coaxing some makes :) there was someone else x-compiling from freebsd here, though i forgot who |
| 00:48:16 | dirkx | Hmm - yes - mapping /sbin/genksyms to the actuall cross compile root seems to at least fix this part of the problem. |
| 00:49:48 | dirkx | General question: is the buildroot environment intended to be platform neutral ? Or was that never intended ? It seems very close - kernel build's are fine - it is all the glibc land which is a mess. |
| 00:50:32 | GoRK | yes in that respect it is because our root libc is not even glibc. it's uClibc |
| 00:50:43 | dirkx | GoRK: - So barely no one else using FreeBSD then ? |
| 00:51:23 | dirkx | Just looking at SlackWare - version 8.0 - is that what I should quickly download and install - or is that tooo new ? |
| 00:51:53 | GoRK | uClibc makes some compiler wrappers that assist in forcing apps to compile against uClibc vs the default libc, so should be no problems there |
| 00:52:45 | GoRK | i prefer debian testing or debian unstable but coming from bsd, you might like slackware. nice and manual |
| 00:53:37 | prpplague | GoRK: ya here a lot of bsd/freebsd ppl use slackware when they must use linux |
| 00:53:39 | dirkx | Which version of debian - I still have 21 minutes to go on the slackware iso download I just started :-) |
| 00:56:21 | GoRK | woody (testing) is the best mix between new fun things and stability |
| 00:56:25 | dirkx | For debian - is 'Patato' the must have - or should it be woody ? |
| 00:56:58 | dirkx | Hmm: ack - woodie - is there a single floppy download ? |
| 00:57:24 | GoRK | if you have fairly common hardware you can net install from a single floppy yes |
| 01:01:14 | dirkx | Aye - I'll try. |
| 01:04:06 | prpplague | has just finished final checkout of router |
| 01:04:19 | prpplague | its 3b time... |
| 01:04:20 | prpplague | beer |
| 01:04:22 | prpplague | butt |
| 01:04:24 | prpplague | bed |
| 01:04:56 | dirkx | Let's see. I've got it to work just fine in NetBSD more than once; unfortunately the MMU of NetBSD/arm does not quite seem to match with the IS2630 box - so I was hoping this was the quicker route. |
| 01:05:35 | prpplague | night all |
| 01:05:38 | dirkx | Yes - I've got the 5v to work just fine. That was just a little bit of wiring. I am bit confused by the design on the site - as to why there need be a switch. I'd rather let the PCI card and bridge handle that. |
| 01:05:38 | GoRK | ahhh netbsd on the tux :) |
| 01:06:04 | GoRK | did you have netbsd running on it? |
| 01:07:42 | Edix | hello anyone here? |
| 01:07:49 | GoRK | in order not to have a switch we'd have to wire one of the arm's unused GPIO lines to a circut to do the voltage switching and rework the pcmcia driver a bit. I think that will probably come with the same circut to let us do software reset of pcmcia cards |
| 01:13:21 | Edix | interesting |
| 01:14:29 | Edix | has anyone figured out if you can bring video in to display on the touchscreen? |
| 01:15:42 | GoRK | Edix: what kind of video? |
| 01:16:37 | Edix | I was wondering if I could use the same screen to play a movie or such on |
| 01:16:54 | dirkx | GoRK: Yes - had some NetBSD running - but not enough - there is somethiing with the MMU which I do not quite understand. |
| 01:16:56 | Edix | would it even look good? |
| 01:17:02 | GoRK | Edix: there's no reason it wouldn't work mmapped, but the processor isn't the fastest beast in the world either.. and there is no hardware to help out things like scaling, etc... plus no floating point math ;) |
| 01:17:15 | Edix | true |
| 01:17:25 | Edix | so it would look really choppy |
| 01:17:34 | Edix | but a random still photograph would look fine |
| 01:18:15 | Edix | what if I wantd to hook a playstation up to it.. could I overide the cpu and go straight into the screen? |
| 01:18:16 | GoRK | wellll i think we will probably see video-conference quality video on the tuxscreen someday... 160x120 or even 320x240 with the right codec should be fine |
| 01:19:07 | Edix | forgive my lack of knowledge just starting to dive into electronic meddling |
| 01:19:16 | Edix | as far as circuts go |
| 01:19:38 | GoRK | hook a playstation up how? there is no video input. it'd be best to rip the screen off entirely and get an ntsc driver for the lcd panel itself |
| 01:20:13 | GoRK | but building all that would probably not save any money over buying an ntsc ready 7 inch lcd |
| 01:20:37 | Edix | how much could I get a ntsc ready lcd? |
| 01:20:48 | Edix | I would really like to have both at once |
| 01:20:59 | GoRK | you can get 5" lcd's that take ntsc video for like $200 or less surplus |
| 01:21:26 | GoRK | they are a lot brighter than the tuxscreen also.. DSTN screen on this thing really isn't that great |
| 01:21:56 | Edix | are you here alot I have to go but have more questions |
| 01:22:55 | GoRK | yes |
| 01:24:18 | dirkx | Hmm- Does linux use the 'portmapper' when working out the NFS mountd port ? It seems to have the ancient SuNOS 635 port hardcoded ? Or is that just a default which will time out ? |
| 01:25:21 | GoRK | yeah there's a portmapper |
| 01:26:02 | GoRK | iirc the other is a fallback |
| 01:26:15 | dirkx | Arg; prefixing '-'-es should be forbidden. |
| 01:26:51 | dirkx | GoRK: - the kernel/boot combo from downloads/v04 from tuxscreen.net seems to really want to talk to 635 only. No portmapper preamble. |
| 01:27:37 | GoRK | dirkx: oh yeah... well that's a uClibc based thing, so it really has minimal nfs support |
| 01:29:04 | GoRK | you might ask andersee about it if/when he comes on here |
| 01:29:08 | GoRK | or ask on the uClibc mailing list |
| 01:29:13 | dirkx | Well - truly minimal ! |
| 01:39:40 | as_ | Nite all/ |
| 01:40:02 | dirkx | anyone seen this one before: |
| 01:40:02 | dirkx | kernel/kernel.o(.data+0x148): undefined reference to `__start___kallsyms' |
| 01:40:02 | dirkx | kernel/kernel.o(.data+0x14c): undefined reference to `__stop___kallsyms' |
| 01:40:02 | dirkx | fs/fs.o(.data+0x41c8): undefined reference to `generic_file_open' |
| 02:18:34 | SpaceCoaster | GoRK: the changes to wheaties.c look great, thanks for re-integrating them |
| 02:18:50 | GoRK | sure |
| 02:19:09 | GoRK | i wanted to be able to unload the module mainly :) |
| 02:19:24 | GoRK | so i fxed the __exit, then i figured might as well do the rest |
| 02:21:41 | SpaceCoaster | The sound on my shanip sounds ok, for the little speaker, just occasional clicks, nothing bad. |
| 02:22:03 | GoRK | that's from tuxphone though. try it on the new kernel and it's quite nice |
| 02:22:23 | GoRK | btw the new kernel implements /dev/dsp as the regular major/minor for /dev/dsp so dont forget to change it |
| 02:22:31 | GoRK | recording doesnt seem to work on the new kernel either... |
| 02:24:49 | SpaceCoaster | how do I use nc? |
| 02:25:16 | GoRK | nc to do what? test recording? |
| 02:25:16 | GoRK | nc -l -p <port number> sets up a listener |
| 02:25:31 | GoRK | nc <ip> <port> sends stdin to another machine |
| 02:26:01 | GoRK | that is the basic way to do it, though there are phenominally more complicated ways of doing things |
| 02:26:50 | GoRK | listeners have to be set up before a remote nc can attach |
| 02:26:59 | SpaceCoaster | cool, never used nc, looks pretty awesome. |
| 02:33:46 | SpaceCoaster | GoRK: so we can record stuff from the handset, what about from the line? |
| 02:34:04 | GoRK | SpaceCoaster: does the mtdblock device not work with serial_flash? |
| 02:34:22 | SpaceCoaster | yes it works |
| 02:35:50 | GoRK | SpaceCoaster: cannot record from the line using this interface, though the new kernel drivers are supposed to support playback/recording via the telephony interface which is supposedly hooked up. I think it's accessed as /dev/dsp1 but it didnt do anything except make bad noises on the regular audio interface. i think maybe the ucb1x00 driver isnt talking to our ucb1200 correctly or something |
| 02:36:41 | GoRK | tuxscreen:/# dd if=/dev/mtdblock3 of=test bs=8192 |
| 02:36:42 | GoRK | dd: opening `/dev/mtdblock3': No such device |
| 02:36:46 | GoRK | but /dev/mtd3 works |
| 02:37:04 | GoRK | wait nm |
| 02:37:32 | SpaceCoaster | did you modload spi and serial_flash? |
| 02:37:46 | GoRK | yes something is just weird |
| 02:38:07 | GoRK | what are the major and minor numbers supposed to be for mtdblock devices? |
| 02:38:23 | GoRK | 31, 0-3 ? |
| 02:40:21 | SpaceCoaster | correct |
| 02:40:44 | GoRK | oh i guess i could try making them block devices :)) |
| 02:40:56 | SpaceCoaster | oops |
| 02:42:38 | dirkx | GoRK: you where right about Debian and Slackware. Not expected thatmuch of a difference between what is all lnux. |
| 02:42:55 | GoRK | what about it? |
| 02:43:41 | dirkx | GoRK: that a freebsd weenie would feel more at home in a tight/clean/spandex Slackware version :-) |
| 02:43:51 | GoRK | oh yeah :) |
| 02:44:31 | dirkx | I am now installing them in parallel - to see which is done easiest (as they all share the same serial-port-on-ethernet fabrik to the tucscreens anyway). |
| 02:44:57 | GoRK | slackware will probably be an easier install |
| 02:48:25 | dirkx | Yep: - you bet. I have a sis 900 pci ethernet. Should that use the SIS driver ? |
| 02:48:57 | SpaceCoaster | GoRK: cat /proc/mtd, does it mention atmel |
| 02:49:04 | GoRK | i dont know. probably. if the module loads up and ifconfig eth0 shows something with a mac address you're probably good to go |
| 02:49:15 | GoRK | SpaceCoaster: yeah it was that i created character not block devices |
| 02:49:47 | SpaceCoaster | GoRK: which kernel is this with? |
| 02:49:56 | GoRK | 2.4.13-ac5-rmk2-tux2 |
| 02:50:21 | GoRK | how many 8192kb blocks are in this device? |
| 02:50:25 | dirkx | GoRK: nai - no load up. Hmm. thanks |
| 02:50:45 | GoRK | err 8192 byte |
| 02:50:46 | SpaceCoaster | 64 |
| 02:50:49 | GoRK | ok |
| 02:50:51 | SpaceCoaster | whatever |
| 02:51:04 | SpaceCoaster | 8192, 8219,... |
| 02:51:44 | SpaceCoaster | shouldn't that be kibibytes? |
| 02:52:14 | GoRK | sure kibibytes |
| 02:52:18 | SpaceCoaster | or is that octets? |
| 02:52:35 | GoRK | dunno |
| 02:52:37 | GoRK | bytes |
| 02:52:45 | GoRK | does erase take forever? |
| 02:53:02 | GoRK | tuxscreen:~# dd if=serialflash-randomin of=/dev/mtdblock3 bs=8192 |
| 02:53:03 | GoRK | serial_read from=0 len=8192 buf=d8878000 |
| 02:53:03 | GoRK | serial_erase addr=0 len=8192 next=363d5952 |
| 02:53:05 | SpaceCoaster | never tried it, not implemented so should be quick :-) |
| 02:54:32 | SpaceCoaster | serial_erase() just returns 0, these blocks don't have to be erased first. |
| 02:54:52 | GoRK | my dd locked down hard |
| 02:54:57 | SpaceCoaster | but if we didn't have an erase the the mtd stuff didn't want to write. |
| 02:55:13 | SpaceCoaster | what is serialflash-randomin ? |
| 02:55:26 | GoRK | 512kb of /dev/urandom |
| 02:55:44 | GoRK | i was going to fill the flash up with that then read it out and compare it |
| 02:55:47 | GoRK | rinse and repeat |
| 02:56:25 | SpaceCoaster | let me try on 2.4.7 |
| 02:57:24 | SpaceCoaster | hmm, it will take quite a long time to write, 20ms per 256 bytes. |
| 02:57:53 | GoRK | should i keep getting status messages? |
| 03:00:35 | SpaceCoaster | I don't get any output, which is odd as it is compiled VERBOSE. |
| 03:03:08 | GoRK | but does it work |
| 03:05:04 | SpaceCoaster | possibly not, when I read it I just get nulls. |
| 03:05:41 | GoRK | it worked before didnt it? |
| 03:05:41 | dirkx | Folks: from blob/LART - if I want *all* output to go to the serial port; what are the right args; i.e. boot kernel console=ttySA0,115200 gives me a panic a bit later. |
| 03:06:25 | GoRK | you have to specify root device and init also |
| 03:06:37 | dirkx | Ah - boot kernel and the root/ramdisk ? |
| 03:06:39 | SpaceCoaster | GoRK: yes it did, I will look at it tomorrow and check in something with read/write functionality, ok |
| 03:06:57 | GoRK | boot console=ttySA0,115200 root=/dev/mtdblock2 init=/linuxrc |
| 03:07:08 | GoRK | SpaceCoaster: cool man!!! |
| 03:07:43 | dirkx | Lovely - out of curiosity - why does boot console=ttySA0,115200 alone not work ? I.e. when the rest is just defaults ? |
| 03:08:50 | SpaceCoaster | GoRK: going to bed, see ya tomorrow. |
| 03:08:52 | GoRK | dirkx: im not sure what the kernel has set as root device, but it's not mtdblock2 :) |
| 03:08:56 | GoRK | SpaceCoaster: adios |
| 03:09:21 | GoRK | 'boot' works because there is a default kernel command line |
| 03:09:39 | GoRK | but if you explicitly specify a commandline you have to give it the whole thing |
| 03:10:22 | dirkx | Or why does it actually use the screen as a console when it really is booted from serial - is there any concept of console device ? Or is it simply the screen/first alwasy ? |
| 03:10:26 | dirkx | GoRK: thanks ! |
| 03:10:47 | GoRK | dirkx: you can have multiple console= devices |
| 03:11:20 | GoRK | boot console=ttySA0,115200 console=tty1 root=/dev/mtdblock2 init=/linuxrc |
| 03:12:13 | GoRK | it doesnt know it waws booted from serial. blob just happens to be listening for input on the serial port |
| 03:17:43 | dirkx | GoRL: yes that solved it. Nice. Now let's see if we can get the 3c515 PCI card recognized. |
| 03:18:16 | GoRK | pci? as in cardbus? |
| 03:18:20 | GoRK | cardbus will not work |
| 03:18:58 | BZFlag | nite |
| 04:45:14 | dirkx | GoRL: yes that solved it. Nice. Now let's see if we can get the 3c515 PCI card recognized. |
| 04:45:57 | dirkx | andersee: are you the maintainer of the buildroot toolkit ? |
| 04:53:58 | andersee | sortof. I wrote it anyway. |
| 05:01:29 | GoRK | time to upgrade from 2.4.9 :) |
| 05:01:57 | andersee | GoRK: whats up? The new kernel is solid? |
| 05:02:05 | andersee | That is very good news |
| 05:02:22 | andersee | Ever find the source of the mount wierdness? |
| 05:02:51 | GoRK | andersee: no i meant on my desktop. the new kernel is getting there on the tux |
| 05:03:07 | GoRK | i got wheaties mostly solid today though |
| 05:03:38 | andersee | cool. I saw the commit logs... |
| 05:04:08 | GoRK | spacecoaster overoptimized it :) |
| 05:04:27 | andersee | I've got 2.2.15-pre2 + a patch for SCSI stuff on my desktop |
| 05:04:36 | GoRK | yesterday we backed changes out to the second version he ever wrote |
| 05:04:59 | andersee | As Knuth says, premature optimization is the root of all evil |
| 05:05:02 | GoRK | yeah i was debating to go with the ac tree which is what ive been doing on my other machines but i did want the new vm now that it's reported to be pretty solid |
| 05:07:09 | AlHaz | I dunno about that new VM |
| 05:07:34 | AlHaz | tried 2.4.13 and 2.4.14 on my dual celeron |
| 05:07:42 | AlHaz | it was pretty stable, unless i tried to run LimeWire |
| 05:07:49 | AlHaz | java gnutella client |
| 05:07:57 | AlHaz | pretty decent gui |
| 05:08:24 | AlHaz | I'd get a null pointer exception caused by the jre about 15 seconds after launching it |
| 05:08:29 | AlHaz | 100% reproducable |
| 05:08:44 | AlHaz | backleveled to 2.2 and everything's fine |
| 05:09:08 | GoRK | well i will try limewire as soon as i reboot |
| 05:09:53 | AlHaz | I'm using limewire 1.6 with jdk 1.1.8 on debian 2.2, fwiw |
| 05:10:05 | GoRK | ok |
| 05:10:11 | AlHaz | and I haven't done anything special with the jvm to make it less of a pig |
| 05:10:23 | AlHaz | I've got ram to spare so i just haven't bothered |
| 05:14:17 | AlHaz | oh, and I'm launching it with the reportedly lame shell script that came with limewire 1.5 |
| 05:22:36 | GoRK | ok time to reboot |
| 05:22:36 | GoRK | brb |
| 05:34:39 | dirkx | andersen: I've been hacking buildroot-tux for FreeBSD - does it make sense to send you a patch ? |
| 05:37:24 | dirkx | andersen; nevermind - our email crossed. |
| 05:37:28 | andersee | sure. But (per the email I sent) you will want to use the "unstable" busybox source, which I have made much friendlier for porting. |
| 05:37:38 | andersee | heh, yup. |
| 05:38:57 | andersee | dirkx: busybox is a multi-call binary that provides most all the unix tools for embedded systems. |
| 05:39:25 | andersee | dirkx: on the phone, it provides cat, cp, mv, vi, sed, etc. |
| 05:39:50 | andersee | dirkx: the busybox versions are much smaller then the GNU (or BSD) equivalents |
| 05:40:44 | dirkx | Ah nice. Just installed a debian and slackware system to actually see what happens with this mksym things and what generates linux/autoconf.h :-) and getting the feeling that there are some deep linux dependencies there. But then again I nearly got as far as bulding the kernel. Except for some ___start__ symbols. |
| 05:41:16 | dirkx | Nice - a few years ago I used the same on a Acorn RISC pc when the first netbsd ports came out. Well worth the time. |
| 05:42:20 | andersee | I've been working on busybox for over 2 years now, and it makes for a pretty solid system. Very configurable. |
| 05:42:28 | andersee | I use Debian myself. |
| 05:42:59 | andersee | I think you will find that 'apt-get' is very similar to the ports system. |
| 05:45:30 | dirkx | Nice - yes - apt-get seems intuitive enough :-) more than enough. The reason for using *BSD was more that I already have a netbsd/freebsd cross compile environment in place for the Acorn and for some developer SA1100 boards. And it would be a shame not to use it. But the phone seems a bit different. MMU was one of the thigns I ran faul on. |
| 05:46:11 | dirkx | By the way - what should (normally) generate the linux/include/linux/autoconf.h file ? The script/Menuconfig ? |
| 05:48:13 | andersee | When you build the kernel, you run 'make menuconfig' (or 'make oldconfig' if you have an .config already). Then you run 'make dep' which builds autoconf.h from your config |
| 06:18:44 | dirkx | andersee: so just a make world is not enough ? |
| 06:25:09 | GoRK | blah. have to recompile the new kernel |
| 06:25:27 | GoRK | apparently alan likes to use io buffers that are variable sizes and linus doesnt |
| 06:29:01 | dirkx | On debian - is there a nice single magic command to get the whole buildroot+buildtools+everything to be fetched with all dependencies, libs, toolchain ? |
| 06:31:34 | GoRK | read www.emdebian.org for instructions on installing the cross compiler and toolchain.. you add a couple lines to your /etc/apt/sources.list, run apt-get update, apt-get install <something> to get all the packages... |
| 06:31:47 | GoRK | ill brb ... hope this boots |
| 06:32:46 | dirkx | GoRK: thanks. |
| 06:48:30 | andersee | dirkx: a 'make world' should work -- assuming you have the needed tools installed |
| 07:02:05 | dirkx | andersee: thanks - debugging further. I suspect there is a '-' in a makefile somewhere - causing me to miss an error. |
| 07:16:25 | GoRK | ahhhh nice |
| 07:16:29 | GoRK | Linux beastor 2.4.15-pre3 #1 Mon Nov 12 00:03:08 CST 2001 i686 unknown |
| 07:16:44 | GoRK | LVM root was messing me up |
| 07:19:50 | andersee | excellent |
| 07:20:36 | andersee | I've found 2.4.15-pre2 to be pretty sold. |
| 07:20:49 | andersee | Havn't tried pre3 |
| 07:22:01 | GoRK | i had to rewrite some functions but it turned out ok |
| 07:22:19 | GoRK | lvm-snap.c was moved over from alan's tree to linus's and had some issues |
| 07:22:38 | GoRK | alan just posted a message to lkml about an hour ago about it |
| 07:25:04 | dirkx | Hmm - on slackware things installed manually fine - and I've got a working build. On debian it says I should use 'apt-get update': |
| 07:25:12 | dirkx | echo deb http://emdebian.sourceforge.net/emdebian unstable main |
| 07:25:20 | dirkx | >> /etc/apt/sources.list |
| 07:25:24 | dirkx | apt-get update <works) |
| 07:25:45 | dirkx | apt-get install task-cross-arm <fails with cannot find package). |
| 07:25:55 | dirkx | has the name changed ? |
| 07:26:11 | GoRK | did apt-get update return errors downloading package lists from emdebian.sourceforge.net? |
| 07:26:29 | dirkx | No it was fine - no errors. Can I reset it to double check ? |
| 07:26:57 | GoRK | yeah just edit /etc/apt/sources.list to make sure that emdebian's line is in there, then run apt-get update again |
| 07:27:04 | GoRK | then try apt-get install task-cross-arm |
| 07:27:06 | GoRK | again |
| 07:27:21 | dirkx | vi /etc/apt.sources.list > has deb http://emdebian.sourceforge.net/emdebian unstable main |
| 07:27:31 | dirkx | playstation:/home/dirkx# apt-get update |
| 07:27:31 | dirkx | Hit http://emdebian.sourceforge.net unstable/main Packages |
| 07:27:32 | dirkx | Ign http://emdebian.sourceforge.net unstable/main Release |
| 07:27:32 | dirkx | Reading Package Lists... Done |
| 07:27:32 | dirkx | Building Dependency Tree... Done |
| 07:27:32 | dirkx | playstation:/home/dirkx# apt-get install task-cross-powerpc |
| 07:27:35 | dirkx | Reading Package Lists... Done |
| 07:27:36 | dirkx | Building Dependency Tree... Done |
| 07:27:38 | dirkx | E: Couldn't find package task-cross-powerpc |
| 07:28:17 | dirkx | Is that 'unstable main' correct ? |
| 07:28:36 | GoRK | try apt-get install gcc-arm |
| 07:28:55 | dirkx | yep - that spins. |
| 07:29:22 | dirkx | Is 'buildroot-tux' for tuxscreen also under apt/deb control ? |
| 07:29:31 | GoRK | dirkx: ok then do this after that installs |
| 07:30:01 | dirkx | Ok - that completed without errors. |
| 07:30:14 | GoRK | apt-get isntall cpp-arm libc6-dev-arm g++-arm libstdc++2.10-arm libstdc++2.10-dev-arm |
| 07:30:19 | GoRK | err |
| 07:30:23 | GoRK | spelling error on install |
| 07:30:49 | dirkx | Says: |
| 07:30:55 | dirkx | playstation:~# apt-get install cpp-arm libc6-dev-arm g++-arm libstdc++2.10-arm libstdc++2.10-dev-arm |
| 07:30:55 | dirkx | Reading Package Lists... Done |
| 07:30:55 | dirkx | Building Dependency Tree... Done |
| 07:30:55 | dirkx | Sorry, cpp-arm is already the newest version |
| 07:30:55 | dirkx | E: Couldn't find package libc6-dev-arm |
| 07:31:40 | GoRK | argh emdebian changed their package names |
| 07:31:55 | dirkx | left "libc6-dev-arm" out and those pkgs install fine. ... done. no errors. |
| 07:32:45 | GoRK | ok try apt-get install binutils-arm cpp-arm libstdc.10-arm libstdc.10-dev-arm |
| 07:33:19 | dirkx | E: Couldn't find package libstdc.10-arm |
| 07:33:45 | GoRK | wtf they must be writing these package files by hand |
| 07:33:46 | GoRK | ok sorry |
| 07:34:11 | dirkx | No trouble - you do not need to aplogize :-) |
| 07:35:21 | GoRK | apt-get install binutils-arm cpp-arm libstdc++2.10-arm libstdc++2.10-dev-arm |
| 07:35:57 | GoRK | they have a Packages and Packages.gz that don't agree and someone's going bonkers changing the names of their freaking packages |
| 07:36:15 | dirkx | Yep 100% joy on that one. So libstdc.10-arm or equiv is not needed ? |
| 07:36:36 | GoRK | no libstdc.10 was apparently renamed to libstdc++2.10-arm |
| 07:36:43 | GoRK | what a pain |
| 07:37:24 | dirkx | Most logical :-) ok - I am now doing a build world in buildroot-tux after getting 'wget' as well. Seems to work. Quite some differences with Slackware in the way this all work. Interesting. |
| 07:37:44 | GoRK | debian is for lazy people.. apt-get wget |
| 07:38:00 | dirkx | :-) yes -I guessed that one (been using BSD ports for years :-) |
| 07:38:16 | GoRK | yeah |
| 07:38:51 | dirkx | By the way - what is the equivalent of 'tip' on Linux (i.e. the serial line application) ? |
| 07:39:00 | GoRK | my favorite apt frontend is called aptitude. + installs - deinstalls _ purges, enter digs down, u updates, q quits, x quits without saving etc |
| 07:39:02 | GoRK | minicom |
| 07:39:13 | dirkx | Aye... |
| 07:39:33 | GoRK | 'g' gets packages and installs them |
| 07:40:13 | dirkx | bunzip2/bzcat - any idea what package they live in ? |
| 07:40:38 | GoRK | bzip2 |
| 07:40:58 | dirkx | Cheers! that works. |
| 07:41:06 | GoRK | packages.debian.org has a search engine |
| 07:41:22 | dirkx | Hmm - ah yes- found it. adding it to sherlock. |
| 07:41:25 | cory | you guys are on the bigscreen tv here |
| 07:41:56 | cory | but your audience is me and thhis other chick who doesn't appear to be close enough to read this small text |
| 07:42:07 | GoRK | haha |
| 07:42:14 | GoRK | i have an LED sign that i irc on sometimes |
| 07:42:30 | dirkx | # # |
| 07:42:30 | dirkx | ###################### |
| 07:42:31 | dirkx | ###################### |
| 07:42:31 | dirkx | ###################### |
| 07:42:31 | dirkx | # # # |
| 07:42:31 | dirkx | # # # |
| 07:42:35 | cory | haha |
| 07:42:50 | GoRK | he was piping banner into the channel lol |
| 07:43:05 | cory | yep |
| 07:43:18 | cory | didn't even have to kick him |
| 07:43:42 | GoRK | haha what were you bannering in here before you got the axe? |
| 07:43:46 | dirkx | Hmm piping banner into irc causes it to crash. shame. |
| 07:43:57 | cory | not crash |
| 07:44:00 | dirkx | Just the word 'BigScreen' :-) using ~| piping. |
| 07:44:01 | GoRK | naw the server just kicks you off for sending messages too fast |
| 07:44:24 | dirkx | Hmm - I had a segfault on this end :-) must not be able to handle the kickoff that well then :-) |
| 07:44:46 | dirkx | Ah well - the joys of MacOS X I suppose. |
| 07:44:53 | cory | I'm in MacOS X |
| 07:45:09 | cory | but ssh'ing to a linux box firewall to a openbsd/sparc box |
| 07:45:23 | cory | linux on this machine seems a bit faster than macosx. heh. |
| 07:45:28 | cory | I liike osx tho |
| 07:47:11 | dirkx | Hmm - you sure about that ? Doing the gump/jakarta.apache.org test harnass takes about 1.5 hours on a G4/660/1Gb versus 2.1 hours on Linux/G4/660/1Gb versus 5.1 hour on a P4/1.2Gz/2Gbyte. For apache/webserver related software this seems a general trend. MacOSX gets close to a Sparc E220 or there about. |
| 07:47:54 | dirkx | Ah - there are some 'tar xv's rather than 'tar xvf-' in the Makefile. No wonder things got confused. |
| 07:48:51 | dirkx | buildroot-tux is spinning nicely now. Had to add some more packages. |
| 07:49:02 | dirkx | GoRK: how long does it typically take on a modern machien ? |
| 07:49:26 | GoRK | dirkx: you'll want the cvs packages too probably |
| 07:49:44 | dirkx | Gork: what are those ? this is this new tinderbox ? |
| 07:49:52 | GoRK | dirkx: dunno... takes me about 10 minutes to build on a 1ghz amd with 512mb ram |
| 07:49:58 | GoRK | cvs? concurrent version system |
| 07:50:14 | dirkx | GoRK: thanks - that is a useful number. |
| 07:51:20 | dirkx | GoRK: -no- not CVS ;-) but you mean that I should just cvs co against the HEAD of buildroot-tux - or more ? |
| 07:52:47 | GoRK | no i was suggesting that you needed cvs to get through a buildroot-tux make world but then i realized that you had to have it because otherwise how would you have even downloaded buildroot-tux?!? |
| 07:53:43 | dirkx | Actually I used a 'v0.4' tarball from http://www.tuxscreen.net/download/v0.4/buidlroot-tux.tar.gz (or there about). |
| 07:54:09 | dirkx | People are very active on head ? (CVS is at the sourceforge I take it). |
| 07:54:47 | GoRK | oh |
| 07:54:47 | andersee | yup |
| 07:55:02 | GoRK | yeah i didnt know there was anything else other than the cvs actually |
| 07:55:47 | dirkx | Ok - I see buildroot-tux there. Does 'kernel' or 'tuxphone' also do me any good :-) ? |
| 07:56:59 | dirkx | Hmm - I certainly need a CVS; in the hour between doing things on the slackware box and debian: ftp://ftp.uk.linux.org:21/pub/people/dwmw2/mtd/cvs/mtd-snapshot-20010928.tar.bz2 |
| 07:57:04 | dirkx | has disappeard :-( |
| 07:58:30 | dirkx | Ha - nice; the sourcefource still allows for 'cvs co .' to get it all. Cool. |
| 07:59:06 | GoRK | the new kernel is upsetting me |
| 07:59:14 | GoRK | i cannot make ucb1200 behave |
| 07:59:40 | andersee | whats it do/not do? |
| 07:59:47 | GoRK | plus, after we can actually get it to behave we are stuck with the problem of rewriting all the input drivers since they have to do their own calibration |
| 08:00:11 | GoRK | it only plays audio. it doesn't record properly on the tux nor does the touchscreen interface work at all |
| 08:00:40 | andersee | ugh |
| 08:01:03 | andersee | least it plays audio well... |
| 08:01:16 | dirkx | calibration - as in Timer counts ? |
| 08:01:52 | GoRK | no calibration as in calibrating the touchscreen - returning the correct pixel when you touch it |
| 08:02:52 | dirkx | That is not too bad - I've done that before on ARM devices. What is the chipset used for the screen. |
| 08:03:08 | dirkx | ? |
| 08:04:04 | GoRK | ucb1200 is the chip that handles touchscreen input brightness, contrast, backlight controls on its gpios and has 2 audio interfaces on it - 1 to a speaker/mic (our external shanip mod-board) and one to the phone line (telephony interface) that is already hooked up |
| 08:04:31 | GoRK | everything is fine in kernel 2.4.7 that buildroot uses, but since that kernel is fairly out of date we are trying to move to newer kernels |
| 08:04:58 | andersee | rmk rewrote the ucb1x00 driver, which is causing us grief |
| 08:05:01 | GoRK | in the newer kernels though the ucb1200 driver has been replaced with a driver for ucb1x00 and the arm's mcp code has been seperated from ucb1200 code |
| 08:05:22 | GoRK | it's actually a better driver... at least from what ive seen; only our hardware doesnt like it too much |
| 08:06:24 | andersee | But we still probably need to give it some tender loving attention with a ball peen hammer. :-) |
| 08:06:42 | dirkx | Aye - I've used an older version of that chip. Are we doing the correction for coordinates ourselfs; or are we letting the linear shear registers on chip handle it ? |
| 08:06:52 | GoRK | we should send rmk a free tuxscreen |
| 08:07:01 | GoRK | i dont think there are registers on ucb1200 to handle it |
| 08:07:22 | andersee | indeed! |
| 08:07:55 | andersee | indeed (re free phone to rmk that is) |
| 08:07:55 | dirkx | Aye - pulling up the datasheet - that is a *very* cheap chip. Hmm - does not matter much - my experience with the shearing has bot been all that great. On the PSION I ended up doing it in code. |
| 08:08:42 | GoRK | there is code in the old kernel driver that could be appolied directly to a userspace touchscreen driver. i wrote the ts input driver for PicoGUI so .. that's what i plan on doing anyway |
| 08:08:56 | GoRK | and converting fbtuxcal to just write the calibration file that any gui can pick up and use |
| 08:09:43 | dirkx | If you stick to linear mappings - or any polinominal - why not ioctl the values into the driver from userland ? |
| 08:09:55 | GoRK | the old ucb1200 driver did two things the new one doesn't (besides work): 1) it had kernel code to set touchscreen calibration and 2) it had code to resample audio to the proper rates |
| 08:10:31 | GoRK | that's exactly what the old driver did! but rmk is pretty much a kernel purist and took that out... as well as the audio resampling.. which pretty much kills me |
| 08:10:50 | GoRK | i mean if you want to play 44.1khz audio you have to upsample it to 46800 or something |
| 08:11:07 | dirkx | :0 |
| 08:11:24 | GoRK | 22050hz is a little better because there is a 22023hz mode.. but over the course of a 1 hour phone call you could get off by a couple seconds |
| 08:11:31 | andersee | Any chance that could be resubmitted? |
| 08:12:18 | GoRK | andersee: i dont know. i really couldnt find anything on the lists or anywhere that explained rmk's motivation for rewriting the ucb1200 driver other than to get mcp broken out of it |
| 08:12:37 | andersee | Perhaps rmk started from scratch and just didn't add those since he didn't need them... |
| 08:13:21 | dirkx | If you diff - you see quite some code still the same. |
| 08:13:41 | andersee | Hmm. Perhaps he wanted the calibration code in the framebuffer. |
| 08:13:58 | GoRK | dirkx: are you looking at the new ucb1x00 vs old ucb1200 drivers? |
| 08:14:03 | andersee | err. |
| 08:14:16 | andersee | the pointer driver |
| 08:15:09 | dirkx | GoRK: yes - trying to work out what is where :-) Drivers which do two things are new to me :-) |
| 08:15:18 | GoRK | yeah from a kernel purists view that's where it belongs - userspace. |
| 08:16:49 | dirkx | Those CVS $Id$ are confusing. Against which master repo are those ? Or doe people like rmk run their own ? |
| 08:17:37 | GoRK | well there is mcp-core and mcp-sa1100 that deal with the arm's interface to ucb1200 in our case. Then there is ucb1x00-core to provide the core chip support and then ucb1x00-ts provides the support for the touchscreen interface and ucb1x00-audio provides the audio interface on the audio pins and on the telecom interface. in the old driver ucb1200-sa1100 was the mcp stuff and ucb1200-core, ucb1200-ts and ucb1200-audio performed similar functions as they do now |
| 08:18:04 | GoRK | it's not one driver that does two things; it's two drivers that share a lot of common code |
| 08:18:52 | GoRK | the cvs id's are probably just rcs id's that rmk uses to keep things straight. i dont know if there is a cvs repository for the arm kernel that is public anyway. rmk uses a fairly elaborate patch submission system of his own |
| 08:19:10 | dirkx | :-) |
| 08:21:08 | GoRK | if you want to mess with 2.4.13 and the tux, patches are at russ.dhs.org/files/tuxpatches |
| 08:22:38 | dirkx | Cheers. I saw those earlier this week :-) |
| 08:22:44 | GoRK | ah |
| 08:23:05 | dirkx | I've kind of gotten lost between thenewer and older versions :-) |
| 08:23:27 | dirkx | Hmm so zlib.h is not part of a base install. |
| 08:24:06 | GoRK | apg-get install zlib1g zlib1g-dev |
| 08:24:24 | cory | apt-get? is that a new one? |
| 08:24:27 | cory | err, apg-get? |
| 08:24:32 | GoRK | yeah apg-get |
| 08:24:40 | GoRK | how about porn-get ? that is a real app! |
| 08:25:06 | dirkx | Ah - it's the dev package :-) |
| 08:25:49 | andersee | dirkx: right. Base install does include header files, static libs and whatnot |
| 08:26:00 | andersee | err. does not. |
| 08:26:21 | dirkx | Nice - that all worked - tuxscreen is rebooting now into a new kernel and image once more. |
| 08:29:31 | dirkx | Shame there is no 'tip' - is there hidden any clever util with does an automatic kernel/image uuencode/download chat-expect with the serial port ? |
| 08:29:52 | cory | think I'm going to have to get debian on my ibook |
| 08:30:25 | GoRK | no. i just keep a minicom open and whenever i need to download a kernel i just do a uuenpipe kernel.image > /dev/ttyS0 from another console and watch the dots in minicom |
| 08:30:48 | GoRK | i'm going to want to watch it boot anyway :) |
| 08:31:26 | dirkx | aye - how do oyu confince minicom to stop bothering me about fake phone numbers and dials ? |
| 08:31:51 | GoRK | go to cOnfigure minicom |
| 08:32:08 | dirkx | Aye |
| 08:32:16 | dirkx | Aye. |
| 08:32:19 | GoRK | you could probably compile up tip |
| 08:32:45 | dirkx | GoRK: -no - very BSD ish or SVR4 ish - but no middle road. |
| 08:33:39 | dirkx | Ah - it was not the modem - it was the flowcontrol ! |
| 08:34:00 | andersee | dirkx: oh yeah. turn off flow control. |
| 08:34:03 | andersee | :-) |
| 08:34:21 | GoRK | oh, yeah you gotta do that |
| 08:34:35 | dirkx | Weird. On the other linux box I got no complaints. Perhaps because I cat-ed there directly to the device. |
| 08:34:35 | GoRK | ok i gotta sleep |
| 08:34:37 | GoRK | nite folks |
| 08:34:44 | andersee | nite |
| 08:34:55 | scanline | night |
| 08:34:57 | dirkx | Nite. |
| 08:36:04 | GoRK | good luck |
| 08:36:53 | andersee | I'll be up for a bit yet (I'm trying to get some work done) and I'll be dropping by here every so often |
| 08:46:31 | dirkx | :-) getting more milage out of the Wireless card now. Great. |
| 08:54:47 | andersee | in the tuxscreen? |
| 08:55:09 | dirkx | yes. Just a normal Wavelan; no crypto working yet. |
| 08:55:21 | dirkx | Hmm- what is # mount -o nolock 192.168.87.1:/home/potato-arm /mnt |
| 08:55:31 | dirkx | supposed to point at ? Some full arm tree ? |
| 08:55:54 | andersee | nfs mount for someone's arm-linux tree no doubt |
| 08:57:15 | dirkx | That 8390.o module - is that just an MII interface module ? |
| 08:58:02 | andersee | believe so |
| 09:13:04 | dirkx | why does busybox disable the virtual screen consoles when it runs from the serial port ? Any reason for that ? |
| 09:13:44 | dirkx | When you download a ramdisk to RAM - is it a MUST to then flash it ? or can one just do some cleverl boot command as to use the RAM version? |
| 09:25:33 | dirkx | Thanks for all the help. Going to bed now. Got wavelan unencrypted to work. (And Pine is happily running to prove it). More mysteries and fun for next weekend. |
| 09:25:34 | dirkx | zzzz. |
| 09:36:30 | scanline | well, ibot... looks like it's just you and me |
| 09:36:35 | | scanline: bugger all, i dunno |
| 09:36:35 | scanline | ibot: you still here? |
| 09:36:40 | scanline | hehe... good :) |
| 09:37:19 | | scanline: what? |
| 09:37:19 | scanline | ibot, the #tuxscreen mascot :) |
| 09:37:27 | scanline | hehe |
| 09:37:43 | | scanline: huh? |
| 09:37:43 | scanline | ibot: You're always here, even when we have server trouble |
| 09:37:58 | scanline | well, maybe not when Tangent has server trouble |
| 09:38:02 | | scanline: what? |
| 09:38:02 | scanline | ibot: you're a little hard to hold a conversation with though |
| 09:38:21 | scanline | oh well... |
| 15:04:00 | SpaceCoaster | RedBaron_: the frequency response of the speakerphone is about 800hz to 11khz, so not much base. If you connected the audio to external speakers etc. it would not be so constrained. |
| 15:05:21 | RedBaron_ | SpaceCoaster: Ah... so thats a constraint on the speaker, not the ucb1200. ok. I was just thinking about using it for a headphone out. Is it amplified or does something else do that? |
| 15:11:26 | SpaceCoaster | RedBaron_: it is amplified, cat /proc/driver/ucb1200/audio |
| 15:12:23 | RedBaron_ | SpaceCoaster: sweet. hmm...maybe I should put my tux back together. since I dont have the money now to complete my portable tux project...at least for a while. |
| 15:15:04 | jacques | anyone here ordered one of the 4-packs? |
| 15:19:36 | | bzflag was last seen on #tuxscreen 12 hours, 38 seconds ago, saying: nite [Mon Nov 12 03:18:58 2001] |
| 15:19:36 | jacques | ibot: seen bzflag |
| 15:30:03 | jacques | whoo! I just sent my order in |
| 15:33:29 | SpaceCoaster | jacques: how many did you go for? |
| 15:34:00 | jacques | SpaceCoaster: 4 this time |
| 15:34:12 | jacques | SpaceCoaster: I'm trying to restrain myself |
| 15:34:20 | SpaceCoaster | jacques: wow, must have great plans |
| 15:34:35 | jacques | SpaceCoaster: I bought a new soldering iron and everything |
| 15:34:56 | jacques | SpaceCoaster: my tuxscreens and my accelerometers should arrive on the same day |
| 15:36:34 | SpaceCoaster | sounds like an interesting project, hmm, accelerometers, what for? |
| 15:36:47 | jacques | SpaceCoaster: I also got a free 25GB laptop drive the other day |
| 15:37:33 | jacques | SpaceCoaster: I want to experiment with making an automotive performance tester |
| 15:38:41 | SpaceCoaster | cool, my car has a GPS system and it uses accelerometers and a gyroscope to correct for car motion/direction. |
| 15:39:06 | SpaceCoaster | so I wondered if you were doing something similar. |
| 15:40:44 | jacques | SpaceCoaster: I mostly want to know straight-line and lateral accel, braking, 0-60, 1/4 mile, and HP |
| 15:41:09 | RedBaron_ | jacques: So what are you going to have the tux do with that info? |
| 15:41:37 | SpaceCoaster | cool, can you get inputs from the car itself, tyre rotation, rpm etc? |
| 15:41:46 | jacques | RedBaron_: I want to know it for my car. then I will put a turbo in my car and take more measurements :-) |
| 15:42:22 | jacques | SpaceCoaster: no need - accel and time is all I need - these accelerometers are 2 axis, so I can actually draw a map of where the car has been |
| 15:43:02 | jacques | SpaceCoaster: not accurate of course, but it would show the general shape of the track and the g-forces |
| 15:43:16 | RedBaron_ | jacques: Hmm.. .okie :) |
| 15:43:25 | jacques | there are similar products out, but they cost $100's |
| 15:43:53 | jacques | RedBaron_: maybe I misunderstood your question - what info were you referring to? |
| 15:44:23 | jacques | and the similar products assume a laptop or palm to do logging and a computer for post-processing |
| 15:44:49 | jacques | for the more complex calcs anyway |
| 15:44:52 | RedBaron_ | jacques: Is this accel info just to be used in track racing? |
| 15:45:12 | SpaceCoaster | jacques: have you looked at the info on a cheap GPS unit, this might provide good speed information. I think they are pretty accurate. |
| 15:45:13 | jacques | RedBaron_: among other things |
| 15:46:05 | jacques | SpaceCoaster: i wonder if there are any cheap single-chip GPS I/Cs yet |
| 15:46:28 | SpaceCoaster | jacques: I was thinking of something like an eTrex. |
| 15:46:44 | jacques | a moving map would be nice |
| 15:47:14 | ctr | i'd love to work for trolltech |
| 15:47:31 | SpaceCoaster | talk to MicroChip32 and kernelwork about the map. |
| 15:47:38 | jacques | i always thought trolls didn't have much tech |
| 15:48:30 | jacques | SpaceCoaster: cool |
| 15:49:57 | RedBaron_ | jacques: I believe most if not all the consumer availible GPS units are standalone setups with serial port interfaces. But just recently one of the big watch companies (forget the name) just started selling a GPS enabled watch. and its not that big. |
| 15:51:41 | jacques | RedBaron_: yeah - I think I might have even seen a CF CPS card |
| 15:51:57 | RedBaron_ | jacques: hmm..cool. |
| 16:00:12 | scanline | is back (gone 06:14:40) |
| 16:33:06 | MicroChip32 | anyone else hear the news from NY this am ? |
| 16:37:25 | prpplague | negative |
| 16:38:37 | MicroChip32 | prpplague: plane crash this morning, sounds like "catistrophic engine failure" tho rather than terrorism. |
| 16:38:49 | MicroChip32 | but it wont help the airlines any |
| 16:39:12 | prpplague | MicroChip32: sorry, thought you meant had we heard any updated news |
| 16:39:30 | MicroChip32 | ah. hehe. |
| 16:40:08 | prpplague | i'm wonder how a company can stay in business when none of the sales ppl will answer the phone.... |
| 16:43:21 | MicroChip32 | hehehe i hear ya, or they let the 'system' answer the phone and keep you on hold for 3 hours |
| 16:44:26 | prpplague | MicroChip32: i've been trying for 3:45 to get a sales person on the phone for three different companies, nothing yet... |
| 16:46:44 | MicroChip32 | heheeh they know its you, they're avoiding you. <G> |
| 16:47:10 | jacques | it's always strange when ppl won't take your money |
| 16:47:50 | kernelwork | usually gets right through to sales and holds a very long time for tech support |
| 16:47:55 | prpplague | jacques: ya, here i am ready to but 1k qty of print servers and i can't get anyone on the phone |
| 16:48:06 | prpplague | s/but/buy |
| 16:48:33 | jacques | prpplague: yep, these companies arent in NY are they? |
| 16:48:37 | kernelwork | I usually call sales if it's the kind of thing that can be support or sales. (More space for secondary mail exchanger is a fine example from last week) |
| 16:49:05 | prpplague | jacques: negative |
| 16:49:14 | kernelwork | Did the plane go down on the main comm backbone into the city? :) |
| 16:49:50 | jacques | it went down amazingly fast with apparently no warning |
| 16:50:28 | kernelwork | I expect that is how many crashes would be anyway. |
| 16:56:04 | scanline | is away: food |
| 17:17:14 | RedBaron_ | some official said that it appears there was an explosion of some type on the plane. and CNN is now saying that one of the engines fell in a different spot than the rest of the plane. |
| 17:18:17 | scanline | is back (gone 00:22:13) |
| 17:18:18 | jacques | yeah, in someone's back yard |
| 17:18:52 | MicroChip32 | wayward engine is in a gas station parking lot |
| 17:19:02 | jacques | ah |
| 17:19:18 | MicroChip32 | the rest of the plane is in a few people's back yards |
| 17:19:49 | jacques | :-( |
| 17:20:04 | MicroChip32 | from what ive heard, it sounds like it was a 'catistrophic engine failure' (thats my words, not official words) |
| 17:22:14 | RedBaron_ | doh. not sure what happened there |
| 17:25:07 | prpplague | jacques: whoo, actually got a sales guy on the phone |
| 17:26:18 | jacques | prpplague: :-) |
| 17:31:47 | SpaceCoaster | just fixed the corruption bug in the serial_flash driver, had to wait for the fifo to flush the data to the flash before asking for it to be written! |
| 17:33:25 | SpaceCoaster | currently takes 41sec to write 512k and 8sec to read 512k |
| 17:34:08 | RedBaron_ | SpaceCoaster: minor details...:) |
| 17:35:28 | SpaceCoaster | RedBaron_: just rambling, ignore me |
| 17:36:03 | RedBaron_ | SpaceCoaster: *chuckle* okie |
| 17:36:56 | SpaceCoaster | RedBaron_: very disappointed that you have put your mobile tuxphone on ice, what gives? |
| 17:37:58 | RedBaron_ | SpaceCoaster: I'm out of a job. :/ and I dont have the cash stored up to live for too long. gotta cut back on a lot of stuff. so I cant buy the batteries and materials to build the new case. I'll get back to it when I have money again. |
| 17:41:23 | MicroChip32 | money? whats that? |
| 17:41:37 | RedBaron_ | I dont know anymore. |
| 17:42:10 | MicroChip32 | pulls out his wallet and shakes the moths out |
| 17:43:59 | jacques | RedBaron_: :-( I am also really interested in a mobile tux |
| 17:46:46 | RedBaron_ | jacques: Well...I built up a little voltage regulator circuit. got my tux running off a 12V battery. Not the battery I'll be using to make it mobile, but I got it to run. :) |
| 17:47:35 | jacques | RedBaron_: cool |
| 17:48:19 | RedBaron_ | jacques: It only drew .3A. total for both the 3.3V and the 5V. That was with the screen on. Pretty damn nice. |
| 17:50:47 | jacques | RedBaron_: that's excellent |
| 17:51:02 | jacques | RedBaron_: is screen backlight controllable? |
| 17:51:53 | RedBaron_ | jacques: You can turn it on and off in software. also control the brightness/contrast. Which I'm sure would effect the power draw some. I just havent gotten around to testing it. I've been gone for the last 3 weeks basicly. |
| 17:53:17 | jacques | RedBaron_: cool |
| 19:24:53 | | salut, SpaceCoaster |
| 19:24:53 | SpaceCoaster | GoRK: hi |
| 19:24:58 | GoRK | haha |
| 19:25:00 | GoRK | hello |
| 19:25:01 | | "Da sky" |
| 19:25:01 | GoRK | what's up? |
| 19:25:08 | | Sorry, GoRK, I'll keep my mouth shut. |
| 19:25:08 | GoRK | ibot shut up |
| 19:25:12 | SpaceCoaster | ibot is chatty today |
| 19:25:23 | | spacecoaster is nothing but an humid half-mouthful of common-kissing slurpee-backwash. |
| 19:25:23 | GoRK | ibot insult spacecoaster |
| 19:25:34 | SpaceCoaster | so true |
| 19:26:03 | SpaceCoaster | GoRK: did you catch my CVS checkin for serial_flash |
| 19:27:01 | GoRK | no i didnt check anything out yet |
| 19:27:07 | GoRK | how is it? |
| 19:27:51 | SpaceCoaster | the corruption problem is history, I needed to wait for 264 bytes to come back from the flash to ensure that 264 had been written. |
| 19:28:34 | SpaceCoaster | The fifo is 8 bytes so this accounted for the corruption on byte 256 (264-8) |
| 19:28:37 | GoRK | ah! sweet so it's good to go? |
| 19:29:40 | GoRK | i see you slab.h'd too |
| 19:30:18 | SpaceCoaster | almost, I'll check in a change to confirm erases, this stops it hanging when MTD tries to erase a page. It needs a positive confirmation. |
| 19:32:12 | GoRK | then i suppose after that is done we should make wheaties use the spi routines then create a kernel patch to send to russ to get these things in the kernel tree where they belong :) |
| 19:32:24 | MicroChip32 | you guys are gonna have all the fun stuff taken care of by the time i get a chance to play with this thing |
| 19:32:48 | GoRK | spi.c and wheaties.c probably go into drivers/misc... serial_flash.c probably goes into drivers/mtd |
| 19:32:58 | SpaceCoaster | GoRK: where is the kernel tree? |
| 19:33:09 | GoRK | eh? |
| 19:33:25 | SpaceCoaster | where is the CVS repository containing the kernel? |
| 19:33:36 | GoRK | i dont think there is one |
| 19:34:01 | GoRK | i mean there is a bunch but i dont think there is *a* repository. i believe rmk uses one for himself |
| 19:34:40 | SpaceCoaster | ok, I think if we have this directory as the definitive location for the drivers that would be best. |
| 19:35:10 | GoRK | which directory? |
| 19:35:44 | SpaceCoaster | the cvs directory tuxscreen/kernel on tuxscreen.net/sourceforge |
| 19:35:53 | GoRK | oh. yeah definately |
| 19:36:01 | GoRK | the makefile doesnt work for me though :( |
| 19:36:15 | GoRK | i have to copy those files all into the kernel source to get them to compile up |
| 19:37:25 | SpaceCoaster | I have a modified Makefile, defines TOPDIR and export_objs. |
| 19:40:51 | SpaceCoaster | GoRK: I checked in a modified makefile. |
| 19:41:01 | GoRK | cool |
| 19:41:48 | SpaceCoaster | can you do "make KERNELDIR=/mykernel INSTALLBASE=/myinstall" ? |
| 19:47:01 | GoRK | yeah it works now |
| 19:48:05 | GoRK | sweet |
| 19:49:02 | SpaceCoaster | I tested the serial_flash and it takes 41sec to write it and 8sec to read it. These could probably be reduced to 25sec and 5sec with some work. |
| 19:49:22 | GoRK | still that is pretty fine |
| 19:49:54 | GoRK | i bet jffs2 will work now w/o any troubles |
| 19:49:59 | SpaceCoaster | it busy waits at the moment for upto 20ms which is not so fine. |
| 19:50:48 | AlHazWork | man, I used to run linux on a 386 with harddrives that didn't have access time better than 20ms |
| 19:51:29 | SpaceCoaster | hmm, you might have to fake an erase first, write 0xff all over it. The erase command isn't doing anything at them moment. |
| 19:52:16 | GoRK | hmm i wonder if erase should actually write blank bytes? |
| 19:53:42 | SpaceCoaster | GoRK: jffs2 looks for 0xff to indicate an erased block. Oh, do you mean hack the erase_page routine to write blocks of 0xff? That would work. |
| 19:54:06 | GoRK | yeah sure. it's technically what's happening right? |
| 19:54:22 | SpaceCoaster | AlHazWork: yeah, looking back this serial flash isn't too shabby. |
| 19:54:27 | GoRK | if you do an eraseall on a flash and then read it is it full of 0x00 or 0xff |
| 19:54:54 | GoRK | like the regular flash chips in here |
| 19:54:55 | SpaceCoaster | what decides between 0x00 and 0xff? |
| 19:56:16 | GoRK | dunno i was just asking if you do the command 'eraseall /dev/mtd1' (where mtd1 is a normal flash chip like our amd flash that is highly tested) then you read the contents, is it full of 0x00 or 0xff ? |
| 19:58:18 | SpaceCoaster | GoRK: the serial flash won't do that yet because the erase page command isn't working |
| 19:58:48 | GoRK | i know |
| 19:59:31 | GoRK | i am just proposing simulating erase by writing whatever the 'default' bytes are on the device |
| 20:00:06 | GoRK | so the question is what state are the bytes on a regular flash chip after an erase? 0x00 or 0xff ? |
| 20:00:17 | SpaceCoaster | ok, when it does work it will fill the page with 0xff, I don't know if this is any different from writing 0xff, except it is faster. Ok let me make a change so that erase_page writes 0xff. |
| 20:00:41 | GoRK | but the amtel chip has an erase command too? |
| 20:01:17 | GoRK | i thought it was not necessary? |
| 20:03:37 | GoRK | ahh yes block erase addressing |
| 20:05:40 | SpaceCoaster | it can do a erase page + write, or a block erase (8 pages) and then plain old writes. That is the quickest way. The JFFS2/MTD stuff is designed around erases that can be queued as separate operations. |
| 20:06:37 | GoRK | well if the erase operation acutally erases then jffs2 should be happy |
| 20:06:52 | GoRK | anyway i will have to do some testing on this later |
| 20:06:56 | GoRK | i must go run some errands |
| 20:07:28 | SpaceCoaster | GoRK: ok, i'll check in the write 0xff, style of erase, see ya later. |
| 20:07:36 | GoRK | later |
| 20:08:46 | GoRK | btw im fairly certain that the DSP is not able to function as a modem |
| 20:08:59 | GoRK | aside from that it can decode the 1200 baud bellcore callerid stuff |
| 20:09:38 | SpaceCoaster | so do you think the modem was implemented in software with the UCB1200? |
| 20:09:46 | GoRK | yes |
| 20:10:10 | SpaceCoaster | wow, that's crazy |
| 20:11:18 | GoRK | and i think we'll probably be able to use it as at least a very slow modem using something like tony fischer's software or fabrice bellard's software |
| 20:11:41 | MicroChip32 | ok what'd i miss? |
| 20:11:56 | MicroChip32 | modem? |
| 20:12:23 | GoRK | check www.ms.mff.cuni.cz/~pacoo0bm/zap/fischer.html |
| 20:12:25 | SpaceCoaster | GoRK: does that mean that audio data is available via the telecom interface on the UCB1200? |
| 20:13:18 | GoRK | SpaceCoaster: yes according to gpsfan it is connected to the telecom interface and 2.4.13's ucb1x00 audio drivers are supposed to support audio from telecom interface |
| 20:13:30 | GoRK | however, they arent working yet :) |
| 20:13:47 | GoRK | strangely, the only thing ucb1x00 related that does work is the audio output |
| 20:13:57 | GoRK | audio input doesnt work, telecom out and in doesnt work, touchscreen doesnt work :-/ |
| 20:14:05 | MicroChip32 | GoRK: why software modem? why not use whatever the tux uses for its internet connection ? |
| 20:14:23 | GoRK | the tux uses a software modem |
| 20:14:28 | MicroChip32 | ahhh |
| 20:14:33 | SpaceCoaster | GoRK: excellent so we can have an answering machine that tells telesales to sod off. |
| 20:14:39 | MicroChip32 | using the dsp eh? |
| 20:14:43 | GoRK | SpaceCoaster: ideally, yes |
| 20:14:51 | GoRK | MicroChip32: no i beleive it uses the ucb1200 |
| 20:14:57 | MicroChip32 | SpaceCoaster: that'd be cool ;) |
| 20:15:13 | GoRK | the released dsp code seems to indicate that the dsp has no internal knowledge of the modem state |
| 20:15:14 | MicroChip32 | add a bit of AI to it ... <G> |
| 20:15:40 | GoRK | plus, the lucent guy said that they could not release the soft-modem software because it was under license |
| 20:15:55 | MicroChip32 | GoRK: that sucks |
| 20:16:26 | GoRK | plus, why would they use a ucb1200 to do only touchscreen when they could have tied it to some gpio's with some (much much cheaper) logic gates? |
| 20:16:35 | GoRK | plus, why is the ucb1200 telecom codec wired to the phoneline? |
| 20:16:55 | GoRK | add it up it says inferno == ucb1200 software modem |
| 20:17:18 | GoRK | the only problem with dr. fischer's code is that it is based heavily on floats |
| 20:17:43 | GoRK | so perhaps if fastfpe is good enough, we'll have something without too much trouble... nwfpe is not going to be able to keep up for v.32 |
| 20:35:44 | SpaceCoaster | Info about a philips softmodem using the UCB1200 - http://www.cetj.com/archives/9803/compphil.shtml |
| 20:36:15 | GoRK | i believe that philips software is only for MIPS |
| 20:37:00 | SpaceCoaster | true but it did mean that philips had software which drove the UCB1200 as a 33.6K modem |
| 20:37:27 | GoRK | yes and they released the ucb1300 to have the sampling capability to deal with 56K and v.90 |
| 20:37:31 | GoRK | so they have 56K also |
| 20:38:22 | SpaceCoaster | does that have higher data rates or higher resolution? |
| 20:38:59 | GoRK | yes |
| 20:45:51 | SpaceCoaster | GoRK: the UCB1200/UCB1300 differences doc http://www-us7.semiconductors.philips.com/acrobat/applicationnotes/AN809_1.pdf doesn't mention any real improvements. |
| 21:03:06 | MicroChip32 | hehe what a ride |
| 21:03:15 | MicroChip32 | i still think they oughta sell tickets :) |
| 21:03:26 | SpaceCoaster | shush, don't tell them what we said about them when they were gone. |
| 21:03:39 | MicroChip32 | hehehee awwwww |
| 21:03:45 | SpaceCoaster | teehee |
| 21:04:24 | MicroChip32 | calls the national inquirer |
| 21:19:14 | SpaceCoaster | GPSFan: can I check with you about my polarised capacitor? |
| 21:22:59 | GPSFan | SpaceCoaster: sure, what's up? |
| 21:23:45 | SpaceCoaster | nothing really, it seems to work fine, just wanted to check. I measured the TR/OUT + as 1.8V when booting and 0.06V after booting. |
| 21:25:31 | GPSFan | Hmm, I would have thought there would be DC on it after it booted. Was that measured with the cap in place? |
| 21:26:09 | SpaceCoaster | no, just bare wires, no shanip |
| 21:26:30 | SpaceCoaster | cat .alias |
| 21:26:33 | SpaceCoaster | oops |
| 21:27:08 | GPSFan | ok, wait 1 while I look over the mongoose schematics again... |
| 21:43:01 | GPSFan | SpaceCoaster: looking at the mongoose schematic, T/R OUT+/- is connected directly to LDOP +/- of the DSP chip. according to page 95 of the DSP chip spec there should be a bout 2Volts DC on each output. It is setup to drive a tel line differentially through a directly connected transformer, so when the + line goes up the - line goes down, and vice versa. since the rest of the shanip circuit is referenced to ground, the only source of + bias is the |
| 21:43:26 | GPSFan | SpaceCoaster: T/R OUT lines. so in short you have it connected correctly. |
| 21:49:01 | SpaceCoaster | GPSFan: not sure I understand much except the last few words, thanks |
| 21:50:59 | GPSFan | ok, I'm just curious why you aren't measuring about 2 volts on the T/R OUT pin. I'm not going to worry about it though, you have audio. |
| 21:51:46 | SpaceCoaster | Yeah it will serve as a reminder that tantalum capacitors are polarised. |
| 21:52:25 | GPSFan | yep, in that value range, I'd usually recommend a non polarized cap. |
| 22:08:36 | BZFlag | hmmm... a linux training lab is considering buying 100 units. |
| 22:09:21 | BZFlag | wishes QWorst would get a clue and stop breaking his DSL line |
| 22:13:02 | BZFlag | woohoo! qwest just got a brain (well at least for the moment...) bbiab |
| 22:23:32 | SpaceCoaster | BZFlag: 100 might break the 'stang! |
| 22:27:17 | BZFlag | heh, could be! that's 800 pounds of phones! |
| 22:30:28 | prpplague | RedBaron_: did i hear you say you were out of work? |
| 22:49:27 | edwardam | how is the tuxscreen coming along? |
| 22:57:59 | Tangent | edwardam : Very very nicely... |
| 22:58:44 | Russ | been gone since friday |
| 22:58:49 | Russ | what'd I miss? |
| 22:59:11 | Tangent | Russ : I don't think there's anything exciting since friday.. minor driver fix |
| 22:59:24 | Tangent | wheaties/ucb1200 stuff |
| 22:59:32 | Russ | right, I got that in my email box (the ub1x00-core.c one) |
| 23:01:00 | Tangent | Very probably.. I haven't been paying too much attention |
| 23:17:28 | pattieja | is away: home |
| 23:27:53 | scanline | is away: food |
| 23:45:33 | scanline | is back (gone 00:17:40) |
| 23:48:39 | GoRK | hello |
| 23:48:52 | GoRK | Russ: is that the one that just moves the reset up a few lines? |
| 23:58:47 | SpaceCoaster | GoRK: hi |
| 23:58:55 | GoRK | SpaceCoaster: what's happening? |
| 23:59:17 | SpaceCoaster | GoRK: I think that are playing musical servers again. |
| 23:59:27 | SpaceCoaster | s/that/they/ |