| 00:01:44 | | no idea, cosmicpenguin |
| 00:01:44 | CosmicPenguin | ibot: What about yo mamma? |
| 00:01:51 | | cosmicpenguin: i haven't a clue |
| 00:01:51 | CosmicPenguin | ibot: do you have a mamma? |
| 00:02:07 | CosmicPenguin | hehe.... ibot is a bastard... :) |
| 00:02:44 | | OK, Russ|werk. |
| 00:02:44 | Russ|werk | ibot: yo momma is nothing but a wretched ass-full of it-fowling snake bait. |
| 00:02:53 | | bugger all, i dunno, russ|werk |
| 00:02:53 | Russ|werk | ibot: what about yo momma? |
| 00:02:59 | | yo momma is, like, nothing but a wretched ass-full of it-fowling snake bait |
| 00:02:59 | Russ|werk | ibot: yo momma |
| 00:05:57 | CosmicPenguin | it-fowling? It fowls up the Segway Human Transport? |
| 00:08:43 | Morn | is away: traveling again vol 3 |
| 00:24:25 | CosmicPenguin | is heading home |
| 00:24:31 | CosmicPenguin | buh bye! |
| 00:24:35 | prpplague_ | l |
| 00:28:28 | | jacques: San Jose, San Jose International Airport, CA, United States; (KSJC) 37-21-33N 121-55-27W 25M; last updated: Mar 29, 2002 06:53 PM EST; Dew Point: 52.0 F (11.1 C); Pressure (altimeter): 30.01 in. Hg (1016 hPa); Pressure tendency: 0.02 inches (0.8 hPa) lower than three hours ago; Relative Humidity: 50%; Sky conditions: clear; Temperature: 71.1 F (21.7 C); Visibility: 10 mile(s); Weather: Mist; Wind: from the NW (310 degrees) at 13 MPH (11 KT); Windchill: 23 F (-5 C) |
| 00:28:28 | jacques | ibot: weather ksjc |
| 00:28:47 | jacques | that's kist wrong |
| 00:28:51 | jacques | just |
| 01:56:19 | Dave__ | can anyone tell me why when I run xlock, it runs behind (visually) any windows open on my desktop ? |
| 01:57:22 | BZFlag | you gave it a -root ? |
| 01:59:05 | Dave__ | BZFlag: it happens when I enter either xlock -inroot or xlock +inroot |
| 02:05:33 | jacques | dammit |
| 02:05:39 | jacques | gzip wont compress a > 2GB file |
| 02:05:43 | BZFlag | odd. don't know. have not used xlock for quite sometime. I use xscreensaver everywhere now. |
| 02:05:53 | jacques | me too |
| 02:07:27 | Russ|werk | ya, it has to do with the headers |
| 02:07:47 | | which is odd because on the whole it wasn't the small green pieces of or why you don't need to mess with ldconfig and such |
| 02:07:47 | jacques | Russ|werk: which ? |
| 02:07:57 | | no shut *your* fscking mouth up! |
| 02:07:57 | jacques | ibot: shut the hell up |
| 02:08:05 | jacques | AAARG |
| 02:08:15 | Russ|werk | ISIZE (Input SIZE) |
| 02:08:15 | Russ|werk | This contains the size of the original (uncompressed) input |
| 02:08:15 | Russ|werk | data modulo 2^32. |
| 02:08:16 | BZFlag | jacques: I thought gzip 1.3.1+ handled > 2GB |
| 02:08:30 | Russ|werk | err...hmmm... |
| 02:08:36 | | BZFlag: I forgot which |
| 02:08:36 | BZFlag | ibot forget which |
| 02:08:38 | Russ|werk | modulo 2^32 |
| 02:08:54 | jacques | BZFlag: coolness if so - but I only have 1.3 and older installed -I will install new version |
| 02:09:22 | Russ|werk | I guess it should do it |
| 02:10:13 | jacques | heh even redhat 7.2 only has 1.3 |
| 02:10:52 | Russ|werk | I have 1.3.2 here (of gzip) |
| 02:11:13 | jacques | the fscking gzi psite is still linked to 1.2.4 |
| 02:11:51 | jacques | where can I get > 1.2.4 ftp.gnu.org only has 1.2.4a |
| 02:12:54 | jacques | nm found beta link |
| 02:13:16 | Russ|werk | I have 1.1.4 of libz |
| 02:13:55 | Russ|werk | lets se....dd if=/dev/zero bs=1M of=out count=2500 |
| 02:14:13 | jacques | i found the beta link to 1.3.3 |
| 02:15:18 | BZFlag | Russ|werk: aw... try /dev/urandom ;-) |
| 02:15:30 | Russ|werk | BZFlag: that will take much longer to compress |
| 02:15:36 | BZFlag | yepper. |
| 02:16:07 | BZFlag | Russ|werk: you have unlimited computing power, don't you? ;-) |
| 02:16:59 | Russ|werk | model name: AMD Athlon(tm) Processor |
| 02:17:07 | Russ|werk | cpu MHz: 751.735 |
| 02:17:54 | jacques | heh |
| 02:27:32 | Russ|werk | jacques: whats in sid works (gzip 1.3.2, zlib 1.1.4) |
| 02:36:32 | jacques | Russ|werk: good to know |
| 02:46:17 | jacques | 2GB limit is so outdated. |
| 03:03:48 | BZFlag | int fseek(FILE *stream, long offset, int whence); |
| 03:06:32 | jacques | :-\ |
| 04:43:30 | jacques | heh |
| 04:43:51 | jacques | I found the answer to most of my questions by searching the linux-arm list |
| 04:43:57 | jacques | about tslib |
| 04:59:09 | | andersee was last seen on #tuxscreen 1 days, 4 hours, 1 minutes and 52 seconds ago, saying: I've been using it here with good results... [Fri Mar 29 00:57:17 2002] |
| 04:59:09 | jacques | ibot: seen andersee |
| 04:59:16 | | jg was last seen on #handhelds.org 21 days, 2 hours, 23 minutes and 15 seconds ago, saying: MonMotha: sorry... [Sat Mar 9 02:36:01 2002] |
| 04:59:16 | jacques | ibot: seen jg |
| 05:01:51 | scanline | is away: fun, games, and explosions |
| 05:11:17 | jacques | anyone know if the tuxscreen hw supports sync ts access? |
| 05:46:59 | jacques | GCC 3 does contain some Xscale knowledge, but all kernels built with |
| 05:46:59 | jacques | these compilers fails to boot. This problem is being looked into by |
| 05:46:59 | jacques | a few people (last I heard). |
| 05:47:03 | jacques | heh |
| 05:56:22 | jacques | hi TomW |
| 05:56:40 | TomW | Hi jacques |
| 05:56:58 | TomW | Just finishing my day here. Tired tonite. |
| 05:58:11 | TomW | I've been thinking about a window manager, not sure what to put my efforts into. |
| 06:06:46 | jacques | what features do you need? |
| 06:09:14 | TomW | Desktop icons / menu to launch apps. I looked quickly at nano-X, but that didn't seem to be that flexible. It looked as if every app you wanted to run needed to be launched seperately from the command line. |
| 06:10:08 | jacques | i think desktop icons are out of vogue with the new small wms |
| 06:10:18 | jacques | but menus are reasonable |
| 06:10:31 | TomW | Okay, but I need menus. Icons I can do away with. |
| 06:10:32 | jacques | also there are several launcher type apps available |
| 06:10:43 | TomW | for nano-X? |
| 06:10:52 | jacques | ops sorry didnt know you meant for nano-x |
| 06:11:00 | jacques | i only think x :-) |
| 06:11:21 | TomW | Ok, that is why some of the guys are running Xfbdev? |
| 06:13:07 | jacques | yeah |
| 06:13:10 | jacques | like me |
| 06:13:22 | jacques | real X(tm) :-) |
| 06:13:48 | TomW | Ok, I guess I grab the latest 4.x sources and start hacking it apart to run on the Tux. |
| 06:15:02 | jacques | TomW: i wrote a howto on that |
| 06:15:15 | jacques | it's on the wiki |
| 06:15:24 | | jacques: i'm not following you... |
| 06:15:24 | jacques | ibot: tinyx howto |
| 06:15:32 | jacques | ibot: search for tinyx |
| 06:15:50 | TomW | cool! Thanks, I will look it over. |
| 06:16:16 | | OK, jacques. |
| 06:16:16 | jacques | ibot: tinyx howto is at http://tuxscreen.net/wiki/view/BuildingTinyX |
| 06:16:28 | jacques | TomW: look at http://tuxscreen.net/wiki/view/BuildingTinyX - it's the most up-to-date |
| 06:20:16 | TomW | bookmarked, now time to get some sleep. cul |
| 07:46:24 | scanline | is back (gone 02:44:33) |
| 08:58:15 | scanline | is away: ZzZzZz.... |
| 15:01:32 | LoneTech | drivers/char/char.o(__ksymtab+0xe8): undefined reference to `spi_cleanup' |
| 15:09:13 | | i heard tuxscreen was http://TuxScreen.net/ order at http://tuxscreen.net/wiki/view/Users/TimRiker and http://tuxscreen.net/scrapbook/images.html or #TuxScreen |
| 15:09:13 | MidnightChaos | what the heck is tuxscreen? |
| 15:55:49 | TomW | jacques_gone: Are you really gone, or just lurking! |
| 15:57:49 | TomW | This is all tentative: It looks like the Lucent engineers made the CPU board so that it could handle a larger Micron DRAM. I am looking at the 4Mx16 (MT4LCM16) pinout and it looks like the signals are all there to take the CPU board up to 64M from 16M. |
| 16:10:26 | TomW | We may even be able to take the Tux up to a full 128M of memory... |
| 16:40:39 | fontenot | LoneTech: I always get that error when I try to build the kernel with gcc3 |
| 17:30:10 | | there is some sort of copyright protection in VHS though |
| 17:30:10 | TomW | BZFlag: there? |
| 17:32:21 | BZFlag | here |
| 17:32:29 | | BZFlag: I forgot there |
| 17:32:29 | BZFlag | ibot forget there |
| 17:32:39 | TomW | I can take the Tux up to 128M DRAM. |
| 17:32:44 | | OK, BZFlag. |
| 17:32:44 | BZFlag | ibot: there is not here |
| 17:33:09 | BZFlag | sweet. 64/64? or 128 on board? |
| 17:34:04 | TomW | 64M on the board, the Micron MT4LC4M16R6-TG6 is a direct fit. |
| 17:35:00 | TomW | They are 4 mbit devices, instead of the 1 mbit devices that are on the board. I happen to have a bunch of the MT4LC4M16 devices laying around here... |
| 17:35:09 | BZFlag | you had to fix the sodimm to get the 64M working, right? |
| 17:35:31 | BZFlag | wanna send me a couple? ;-) |
| 17:36:27 | BZFlag | or are there 4 mem chips... hmmm. |
| 17:37:27 | TomW | Yes, with the addition of 6 additional signal wires, the SODIMM can be taken to 64M. There is no pads on the SODIMM, but a quick check of the SODIMM pinout shows the signals there. Also, they graciously added vias for each of the missing signals. |
| 17:38:06 | TomW | I'll trade ya, two more Tuxes for 10 pcs of DRAM. |
| 17:38:23 | TomW | I paid $26 per ram. |
| 17:38:41 | BZFlag | heh. what do you want for an upgraded tux? ;-) |
| 17:39:01 | BZFlag | I've got a 64M sodimm here. |
| 17:39:38 | TomW | I need someone to help me with the mapping of the DRAM via the ARM software. I never did understand the ARM ram stuff.. |
| 17:39:56 | BZFlag | got the sa1100 pdf? |
| 17:40:27 | BZFlag | the mem config registers are fairly straight forward. |
| 17:40:48 | TomW | Yes, and I just buzzed the board out to check the pinout of the DRAM footprint, all the required signals are there. (God bless their little hearts). |
| 17:41:38 | BZFlag | I know there were systems with 32M on board during development. |
| 17:41:52 | BZFlag | I don't think they ever tested a 64M on board unit. |
| 17:42:42 | TomW | Oooooooooohhhhh! Arrow Electronics has those DRAMs for only $7.35 per! |
| 17:42:46 | BZFlag | you have a Z? (/me is still looking for someone to figure out where jtag is ;-) |
| 17:42:59 | BZFlag | sweet! |
| 17:43:30 | TomW | So, for about $60 and some sweat, we could have 128M Tuxes. |
| 17:44:12 | TomW | I have a surface mount rework kit (http://www.Zephyrtronics.com) |
| 17:45:10 | TomW | You know, the only reason that they had a 32M Tux was due to the densities being offered at that time of the development (circa 1996)? |
| 17:45:35 | TomW | I don't know if 16Mbit densities were commonly available back then... |
| 17:45:56 | BZFlag | 1997 or so. yeah. |
| 17:46:00 | TomW | Who did the original mapping of the DRAM for the Tux? |
| 17:46:09 | BZFlag | in blob? russ and I. |
| 17:46:54 | BZFlag | we'd make it more generic, but then we get 8 1M regions which linux does not like. |
| 17:47:37 | BZFlag | the linux kernel decompressor for arm needs to handle the smaller memory regions, then we can change blob. |
| 17:47:55 | BZFlag | it assumes a 4M region to decompress the kernel into. |
| 17:48:01 | TomW | Ahh, cool. Let me replace the DRAM on one of the units. I am thinking this, that I can replace the DRAM with the larger parts and then the Tux will still see 16Meg of DRAM on board, then remap the DRAM Controller (etc) and should get the Full 64MegBytes? |
| 17:48:17 | BZFlag | I suppose we could have blob decompress into the right places. |
| 17:48:35 | TomW | I have a JTAG dongle. |
| 17:48:40 | BZFlag | yes, that should work. |
| 17:48:54 | TomW | hee hee hee! |
| 17:48:58 | TomW | Yes! |
| 17:49:03 | BZFlag | I install a 32M sodimm and with the current maps it works as an 8M. |
| 17:50:19 | PuckCh | Hello. |
| 17:50:28 | TomW | Your 64M SODIMM may not work, unless the DRAMs on that card are organized as 12 rows X 10 columns, the 13 column X 9 row devices will not work on the Tux. |
| 17:51:33 | BZFlag | #if defined SHANNON |
| 17:51:33 | BZFlag | mdcas0: .long 0xc71c703f |
| 17:51:33 | BZFlag | mdcas1: .long 0xffc71c71 |
| 17:51:33 | BZFlag | mdcas2: .long 0xffffffff |
| 17:51:33 | BZFlag | mdcnfg: .long 0x0334b21f |
| 17:51:34 | BZFlag | mcs0: .long 0xfff84458 |
| 17:51:36 | BZFlag | #endif |
| 17:51:38 | BZFlag | that's from cvs blob. |
| 17:51:55 | TomW | only 12x10 will work. The DRAM on the card now is a 10x10 organization and the footprint for the devices is for the 12x10 devices. IIRC, the DRAM controller is very unforgiving about mixing RAM organization. |
| 17:52:13 | BZFlag | yes. |
| 17:52:54 | TomW | Ok, over the next few days, I will upgrade on of my units, then get in touch with you abt any questions for the mapping. |
| 17:52:57 | BZFlag | with the other config, my 32M sodimm works, but the 64M will not cause the sodimm has a reset line or something wired to the next address line. |
| 17:53:09 | BZFlag | have you build blob from source? |
| 17:53:14 | TomW | Cut & Jumper? |
| 17:53:23 | BZFlag | yeah, that's what is needed. |
| 17:53:24 | TomW | Yes, have built blob. |
| 17:53:39 | TomW | Not run blob that I build, but... |
| 17:53:39 | BZFlag | cool, then just change the regs above. |
| 17:54:05 | PuckCh | I'm trying to make an image with buildroot-tux, but it say undefined reference to `spi_cleanup' in the kernel compilation. |
| 17:54:23 | TomW | What about the ARM kernel, isn't there some mapping or such also needed? I saw that RMK had a selection for the shannon in menuconfig for a 32M unit? |
| 17:54:52 | PuckCh | what's strange, is I have do this yesterday on my x86 without problem |
| 17:55:28 | PuckCh | now, i have just installed the toolchain on a UltraSPARC to work with, and the problem is on it. |
| 17:56:00 | PuckCh | I think it's not toolchain-related, because I have successfully compiled PicoGUI with it before. |
| 17:57:01 | BZFlag | http://www.lart.tudelft.nl/doc.php3 <- sa1100 manuals. |
| 17:57:01 | TomW | PuckCh: Why do you assume that the Spark toolchain is not at fault? |
| 17:57:41 | TomW | BZFlag: already have it,but tnx. |
| 17:57:42 | BZFlag | TomW: the kernel option is an ugly hack. |
| 17:57:54 | BZFlag | it uses the 32M sodimm and disables the 8M on board. |
| 17:57:57 | PuckCh | TomW: I have used it for compiling pgserver from PicoGUI, without problem. |
| 17:58:15 | BZFlag | so the kernel is running at 0xd000 instead of 0xc000 |
| 17:58:19 | TomW | BZFlag: From what I read from the Arm Kernel list, anything to do with RAM on an ARM is an ugly hack! |
| 17:59:27 | TomW | AHHHH! Okay, so the kernel may have to be moved higher to allow for the larger RAM space. |
| 17:59:30 | BZFlag | PuckCh: a kernel compile is much more intensive than a normal app compile. |
| 18:00:01 | BZFlag | the only reason the kernel had to be moved, was that it did not handle the 8 1M regions. |
| 18:00:05 | TomW | PuckCh: like he said, the kernel is the stress test for the toolchain. |
| 18:00:18 | BZFlag | it the regions are larger, it can stay low. |
| 18:00:52 | BZFlag | PuckCh: what you are saying is along the lines of |
| 18:00:57 | PuckCh | BZFlag, Tomw: right. but as there was some email against SPI, maybe there was some patches on this in the past. |
| 18:01:28 | BZFlag | PuckCh: "well it built hello.c, so it must work". that's hardly a comprehensive test. |
| 18:01:31 | TomW | Okay. As I understand it. ARM doesn't map the RAM into contigous sections. They are scattered through the memory map, what they have to do on ARM is to remap those regions so that they appear to be contiguous? |
| 18:02:05 | PuckCh | BZFlag: hummm... pgserver is not really a hello.c program. ;) |
| 18:02:17 | BZFlag | TomW: yes. it just simpifies the view in the kernel once the mmu is live. |
| 18:02:41 | BZFlag | PuckCh: it's more than hello.c, true, but not nearly a kernel. |
| 18:02:42 | TomW | BZFlag: Okay. Time for a shower, then I have to go do laundry. :-( |
| 18:03:14 | BZFlag | TomW: ok so... |
| 18:03:33 | PuckCh | BZFlag: OK. I will look more in detail the problem. |
| 18:03:52 | TomW | BZFlag: so, I will have to play later. :-/ |
| 18:04:16 | BZFlag | I'm interested in a swap for an upgraded unit when you get that far. ;-) |
| 18:04:25 | BZFlag | catch ya later then. |
| 18:04:56 | BZFlag | PuckCh: can you paste the exact error here? |
| 18:05:11 | PuckCh | ok |
| 18:05:25 | PuckCh | arm-linux-ld -p -X -T arch/arm/vmlinux.lds arch/arm/kernel/head-armv.o arch/arm/kernel/init_task.o init/main.o init/version.o \ |
| 18:05:25 | PuckCh | --start-group \ |
| 18:05:25 | PuckCh | arch/arm/kernel/kernel.o arch/arm/mm/mm.o arch/arm/mach-sa1100/sa1100.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \ |
| 18:05:25 | PuckCh | drivers/serial/serial.o drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/ide/idedriver.o drivers/sound/sounddrivers.o drivers/mtd/mtdlink.o drivers/pcmcia/pcmcia.o drivers/net/pcmcia/pcmcia_net.o drivers/net/wireless/wireless_net.o drivers/video/video.o drivers/input/inputdrv.o \ |
| 18:05:28 | PuckCh | net/network.o \ |
| 18:05:30 | PuckCh | arch/arm/fastfpe/fast-math-emu.o arch/arm/lib/lib.a /hd/a4/home/obornet/DEV_HOME/TUXSCREEN/cvs/buildroot-tux/build/linux/lib/lib.a \ |
| 18:05:33 | PuckCh | --end-group \ |
| 18:05:35 | PuckCh | -o vmlinux |
| 18:05:37 | PuckCh | drivers/char/char.o(__ksymtab+0xe8): undefined reference to `spi_cleanup' |
| 18:05:39 | PuckCh | make: *** [vmlinux] Error 1 |
| 18:05:41 | PuckCh | end of paste ;) |
| 18:06:03 | PuckCh | my opinion is the spi.o is not included in the link. |
| 18:08:04 | PuckCh | I must eat now. I will be back later. |
| 18:16:24 | BZFlag | ok. hmm... |
| 18:17:20 | prpplague_ | morning all |
| 18:17:26 | prpplague_ | what be happening? |
| 18:17:33 | BZFlag | not much. |
| 18:18:04 | BZFlag | TomW is looking into building a 128M tux. |
| 18:18:13 | prpplague_ | nice |
| 18:18:22 | prpplague_ | desoldering the onboard ram? |
| 18:18:36 | prpplague_ | or just adding to address buffers? |
| 18:18:36 | BZFlag | yep |
| 18:18:55 | prpplague_ | cool |
| 18:19:00 | BZFlag | replacing the on board and fixing the sodimm |
| 18:19:20 | prpplague_ | nice hack value |
| 18:19:24 | BZFlag | yepper |
| 18:20:11 | prpplague_ | if i could ever gets this handheld data collection app done, i'm going to get back to hacking on my tux |
| 18:20:48 | BZFlag | PuckCh: hmmm... remove char.o and rebuild. char.o should include spi.c from what I can tell. |
| 18:30:57 | PuckCh | BZFlag: right. spi.o is inclued in char.o. |
| 18:44:35 | LoneTech | drivers/char/char.o(__ksymtab+0xe8): undefined reference to `spi_cleanu |
| 18:44:47 | LoneTech | how to fix this? |
| 18:45:05 | BZFlag | LoneTech: you too? hmmm. |
| 18:45:07 | PuckCh | :) |
| 18:45:19 | PuckCh | maybe not my toolchain ? |
| 18:45:46 | BZFlag | does rm -rf build/linux;make linux |
| 18:45:51 | LoneTech | toolchain is vanilla from toolchain-source package |
| 18:46:33 | PuckCh | I have a "home-made" toolchain under UltraSPARC (just made, testing it now) |
| 18:47:15 | LoneTech | I just built standard stuff from debian sid, using toolchain-source and dpkg-cross packages |
| 18:47:35 | LoneTech | kernel source tree built by cvs buildroot |
| 18:48:31 | PuckCh | LoneTech: same for me. I have follow the instruction at http://www.musenki.com/~pj/debian-xcompile.html for building the toolchain. |
| 18:48:56 | LoneTech | I just used /usr/share/doc/toolchain-source/README |
| 18:50:34 | PuckCh | ok. same kind of instructions. |
| 18:51:46 | LoneTech | but spi_cleanup is in spi.o.. |
| 18:52:38 | LoneTech | unless the compiler mistook {} for ;? |
| 18:52:46 | PuckCh | i have try to add static before void __exit spi_cleanup at line 131 of spi.c. |
| 18:53:10 | PuckCh | link give then another error : |
| 18:53:10 | BZFlag | what version of the kernel are you two using? |
| 18:53:12 | PuckCh | undefined reference to `local symbols in discarded section .text.exit' |
| 18:53:26 | LoneTech | PuckCh: that would mean not exporting it |
| 18:53:33 | LoneTech | discarded section. |
| 18:53:39 | LoneTech | it's because it's an exitfunc |
| 18:53:43 | PuckCh | sources/dl/linux-2.4.18.tar.bz2 |
| 18:53:51 | LoneTech | which doesn't make sense in a static executable that does not exit |
| 18:55:47 | LoneTech | removing the EXPORT_SYMBOL ought to make sense, maybe |
| 18:56:11 | LoneTech | that function does not need to be called by other modules |
| 18:56:31 | LoneTech | it should only be called when the spi module is unloaded. in this case it's not even a module, so the section was discarded. |
| 18:56:35 | LoneTech | make sense? |
| 18:57:08 | TomW | BZFlag: miscalculated the DRAM size: 32MegByte on mainboard + 32MegByte on SODIMM == 64MegByte total. |
| 18:58:44 | BZFlag | oh. 64M on board is not possible then? |
| 18:59:07 | BZFlag | what version of the kernel are you two using? |
| 18:59:21 | LoneTech | I thought it was possible to force feed it a 64MB SODIMM? |
| 18:59:22 | PuckCh | LoneTech: OK. Removing EXPORT_SYMBOL for the cleanup function correct the problem : I have now a vmlinux file :-))) |
| 18:59:35 | LoneTech | BZFlag: whatever buildroot downloaded.. |
| 18:59:52 | BZFlag | gcc -v ? |
| 19:00:13 | BZFlag | ok, arm-linux-gcc -v ? |
| 19:00:33 | LoneTech | buildroot linux 2.4.18-rmk2-tux1, gcc version 3.0.4 |
| 19:00:38 | LoneTech | it's not a gcc problem |
| 19:00:50 | LoneTech | there's a macro call to export the cleanup function at the very end of spi.o |
| 19:00:52 | PuckCh | hoops ! 3.0.4 ! Like mine. |
| 19:00:53 | BZFlag | it's likely a gcc 3.0 problem. |
| 19:00:54 | LoneTech | it should not be there |
| 19:01:21 | BZFlag | gcc 2.95.2 just worked fine for me. |
| 19:02:28 | LoneTech | removing "EXPORT_SYMBOL(spi_cleanup);" made it build without comment here |
| 19:03:15 | PuckCh | same for me. |
| 19:03:34 | LoneTech | since the function does nothing anyway, I reckon it can't do any harm |
| 19:07:31 | PuckCh | ok. will be back later : hockey game on the TV. :-) |
| 19:08:44 | LoneTech | Linux tuxscreen 2.4.18-rmk2-tux1 #9 Sat Mar 30 20:07:32 CET 2002 armv4l unknown |
| 19:08:46 | LoneTech | yay! |
| 19:15:54 | BZFlag | back later... |
| 19:24:50 | | niihau, prpplague_ |
| 19:24:50 | prpplague_ | SpaceCoaster: howdy |
| 19:24:55 | prpplague_ | andersee: Howdy |
| 19:25:20 | prpplague_ | andersee: got my gf app running yet? lol |
| 19:25:20 | andersee | morning |
| 19:25:28 | andersee | hehe |
| 19:26:13 | prpplague_ | andersee: seriously, hows the new uclibc doing? getting good feed back? |
| 19:26:18 | andersee | I've been working on my wfe app for the last 7 years and I still don't have all the bugs worked out. |
| 19:26:38 | andersee | Yeah. I'm working on a new configuration/build system |
| 19:41:19 | prpplague_ | andersee: how do you find time to work on all this stuff, seems like i'm always tied up with writing code to pay the bills |
| 19:48:48 | | morn was last seen on #handhelds.org 19 hours, 39 minutes and 56 seconds ago, saying: is away: traveling again vol 3 [Sat Mar 30 00:08:52 2002] |
| 19:48:48 | prpplague_ | ibot: seen morn |
| 19:49:08 | | Morn was last seen on #handhelds.org 19 hours, 40 minutes and 16 seconds ago, saying: is away: traveling again vol 3 [Sat Mar 30 00:08:52 2002] |
| 19:49:08 | prpplague_ | ibot: seen Morn |
| 20:19:19 | andersee | prpplague: so am I... |
| 20:20:10 | andersee | prpplague: right now, I have someone paying me for uClibc development... |
| 20:26:08 | prpplague_ | andersee: lucky bastard |
| 20:28:44 | andersee | hehe |
| 20:32:52 | prpplague_ | andersee: i'm stuck doing handheld medical data collections apps for the next few weeks |
| 20:44:56 | BZFlag | andersee: new config/build for uclibc right? not tuxscreen. |
| 20:45:59 | andersee | BZFlag: right |
| 20:46:17 | andersee | BZFlag: Though it will effect the tuxscreen build a little bit |
| 20:46:41 | BZFlag | np, expected. |
| 20:46:53 | BZFlag | you saw I chopped the makefile up, yes? |
| 20:46:57 | andersee | BZFlag: right now I am adding splitting out jffs2root.mk so I can add other build targets as well (ext2 for example) |
| 20:47:15 | BZFlag | ok, that makes sense. |
| 20:48:52 | andersee | Why is strace adding man pages? |
| 20:49:04 | BZFlag | cause it's make is braindead. |
| 20:49:18 | BZFlag | they are in stage though, not root. |
| 20:49:49 | andersee | Perhaps the final jffs2root target needs a 'rm -rf $(TARGET_DIR)/usr/share/man' |
| 20:49:55 | andersee | just in case... |
| 20:49:57 | BZFlag | in openzaurus, we have an openzaurus.mk that has all the targets. |
| 20:50:14 | BZFlag | and the top level make just maps all: openzaurus |
| 20:50:24 | andersee | I have a number os additional .mk targets I can add in for you |
| 20:50:40 | BZFlag | might be nice to have all: just print the possible targets, and then have to specify them on make. |
| 20:50:56 | BZFlag | ie: make openzaurus or make shannon etc. |
| 20:51:26 | andersee | BZFlag: I have genext2fs hotplug mkdosfs mke2fs mkntfs zlib slang newt all ready |
| 20:51:29 | BZFlag | add away ;-) please include email/contact in each one. |
| 20:51:40 | andersee | Oh, sfdisk too |
| 20:52:01 | andersee | And another one, but I'm not adding that. :) |
| 20:52:18 | BZFlag | another one? /me is curious |
| 20:52:31 | BZFlag | mkntfs? like we need that? |
| 20:52:34 | andersee | My project for the IRS |
| 20:52:40 | BZFlag | heh |
| 20:52:52 | andersee | I use it for that... |
| 20:53:00 | andersee | Otherwise, pretty useless |
| 20:53:10 | BZFlag | yep. add it anyway if you like. |
| 20:53:15 | andersee | pciutils too |
| 20:53:21 | andersee | (lspci and friends) |
| 20:54:06 | andersee | thinks this build system makes Lineo's graphical tool look like a piece of junk... :-) |
| 20:54:36 | BZFlag | TomW: 32M sodimm works with no hw mods, the 64 would need a hw mod. |
| 20:55:15 | BZFlag | still would need keeplists to get to tw level. that's about it. |
| 20:55:27 | andersee | BZFlag: I need to get busybox 0.60.3 out so we can have color `ls' on the tuxscreen |
| 20:55:31 | BZFlag | I'd like to convert to .ipkg or similar at somepoint. |
| 20:55:35 | TomW | Ok. I have a short on the board here someplace, I replaced the DRAM and tried to run it. The Tux just played "dead". |
| 20:56:08 | BZFlag | andersee: agreed! ;-) you saw I added microcom? I hope someone(tm) will work on the softmodem now. ;-) |
| 20:56:35 | BZFlag | TomW: pick up the fingers for the extra address pins and try that. |
| 20:57:02 | andersee | BZFlag: Has anyone posted an mtd tarball yet? Use of CVS is pretty lame... |
| 20:57:07 | andersee | BZFlag: Hmm |
| 20:57:11 | BZFlag | 0.60.3 will be "make config" style? if so, I vote for .61.0 |
| 20:57:29 | andersee | BZFlag: I think we can use the Debian package. http://packages.debian.org/testing/utils/mtd-tools.html |
| 20:57:39 | andersee | BZFlag: Nope. 0.60.3 is just bugfixes |
| 20:57:48 | andersee | BZFlag: Same config system as always |
| 20:57:52 | BZFlag | + color ls. ;-) |
| 20:58:21 | andersee | BZFlag: That will be the last of the 0.60.x series. I won't work on the 0.60.x tree anymnore after this release |
| 20:58:38 | BZFlag | 20011217? hmm. |
| 20:58:48 | andersee | BZFlag: Lemme adjust the mtd config and try it... |
| 20:59:34 | BZFlag | it might be nice to check for mkfs.foo on the path before even trying to build those host binaries. |
| 21:00:32 | BZFlag | MKFSJFFS=$(which mkfs.jffs2) or the mtd/util/ version if not found. |
| 21:01:00 | BZFlag | apt-get mtdutils works better for me than building it. |
| 21:01:48 | BZFlag | well.. mtd-tools, but you knew that. |
| 21:08:29 | prpplague_ | anyone know if infodead.org is back up? |
| 21:11:57 | BZFlag | MKFS_JFFS2:=`if which mkfs.jffs2 ; then true ; else echo $(MTD_DIR)/util/mkfs.jffs2 ; fi` |
| 21:12:02 | BZFlag | how's that look? |
| 21:13:05 | BZFlag | MKFS_JFFS2:=`which mkfs.jffs2 || echo $(MTD_DIR)/util/mkfs.jffs2` would be simpler I suppose. |
| 21:15:38 | andersee | prpplague: I just changed things to no longer depend on infradeed |
| 21:16:12 | andersee | prpplague: I now use the debian source package from mid December, since @.debian.org is more available |
| 21:22:24 | BZFlag | hmm... `` does not expand when set... |
| 21:22:30 | BZFlag | andersee: did you check it in? |
| 21:23:02 | andersee | yup |
| 21:23:47 | andersee | BZFlag: I bet we can attach patches to the Makefiles for those targets... |
| 21:23:58 | andersee | BZFlag: Keep things together or something |
| 21:24:07 | andersee | ponders |
| 21:38:56 | BZFlag | check out my commmit |
| 21:39:30 | BZFlag | ugh.. conflict... |
| 21:41:00 | BZFlag | ok, committed. |
| 21:42:39 | BZFlag | now it won't even dl mtd unless you don't allready have mkfs.jffs2 |
| 21:45:07 | andersee | BZFlag: sneaky. Looks good |
| 21:45:37 | andersee | BZFlag: I just added support for building root as ext2, as a proof of concept |
| 21:51:22 | TomW | BZFlag: ok, it is running. It also reports that it has 16Meg on the mainboard (no changes to blob & no SODIMM) |
| 21:52:45 | TomW | BZFlag: with the SODIMM installed, it reports 24MegByte total. I dunno how much of it is usable.... |
| 21:54:08 | BZFlag | should use all 24. |
| 21:54:26 | TomW | wonder how I can tell... |
| 21:54:39 | TomW | run X or something? ;-) |
| 21:55:29 | BZFlag | cat /proc/meminfo |
| 21:59:18 | TomW | total: used: free: shared: buffers: cached: |
| 21:59:18 | TomW | Mem: 22630400 3563520 19066880 0 4096 888832 |
| 21:59:18 | TomW | Swap: 0 0 0 |
| 21:59:18 | TomW | MemTotal: 22100 kB |
| 21:59:19 | TomW | MemFree: 18620 kB |
| 21:59:19 | TomW | MemShared: 0 kB |
| 21:59:21 | TomW | Buffers: 4 kB |
| 21:59:23 | TomW | Cached: 868 kB |
| 21:59:25 | TomW | SwapCached: 0 kB |
| 21:59:27 | TomW | Active: 584 kB |
| 21:59:29 | TomW | Inactive: 1048 kB |
| 21:59:31 | TomW | HighTotal: 0 kB |
| 21:59:33 | TomW | HighFree: 0 kB |
| 21:59:35 | TomW | LowTotal: 22100 kB |
| 21:59:37 | TomW | LowFree: 18620 kB |
| 21:59:39 | TomW | SwapTotal: 0 kB |
| 21:59:41 | TomW | SwapFree: 0 kB |
| 21:59:53 | TomW | That is with the SODIMM. |
| 22:00:12 | TomW | is away: doing laundry |
| 22:00:14 | BZFlag | just the top would have been enough. Mem: 22630400 |
| 22:04:14 | BZFlag | andersee: debian cvs snapshot can still expire. just not as often. |
| 22:04:33 | BZFlag | imho cvs should still be an option. |
| 22:05:53 | andersee | BZFlag: true enough. Feel free to put it back. Perhaps with a USE_MTD_CVS and a USE_MTD_DAILY_SNAPSHOT option. For the latter, we could calculate yesterday's snapshot filename... |
| 22:06:15 | BZFlag | good thought. |
| 22:10:01 | andersee | We should add PATCH_DIR:=$(SOURCE_DIR)/patches and put all patches in there |
| 22:10:45 | andersee | BZFlag: Hmm. As I think about it, I'd really like to keep patches with the buildroot makefile |
| 22:11:41 | andersee | BZFlag: Perhaps we need to create a PACKAGES dir, and each file in there can contain a Makefile (per current practice) plus N patches, which are automagically applied |
| 22:12:16 | andersee | s/each file/each directory/ |
| 22:14:30 | BZFlag | andersee: hmm.. don't agree. |
| 22:14:40 | BZFlag | I see patches as just another source. |
| 22:14:50 | BZFlag | I'd like to refer to all of em as sources |
| 22:15:40 | BZFlag | the makefile needs to know where to get the sources (including patchs) so it can know how to apply them as well. |
| 22:16:47 | andersee | Ok. Sources are per package. Some sources are local only (such as patches or some source tarballs), while other are remote. It is good to keep related things close together.... |
| 22:17:55 | PuckCh | i'm back. Hockey games ended. News posted. All is OK for that. |
| 22:18:24 | PuckCh | but, problems with buildroot-tux... |
| 22:18:26 | BZFlag | heh, depends on what you call related. I like being able to rm -rf sources/dl |
| 22:18:54 | PuckCh | tuxscreen-kernel is too big : 933560 bytes :-( |
| 22:19:24 | BZFlag | PuckCh: another 3.0 ism. |
| 22:19:37 | PuckCh | i think so. |
| 22:19:42 | BZFlag | PuckCh: 2.95.2 builds: 899984 Mar 30 15:00 tuxscreen-kernel |
| 22:20:38 | PuckCh | BZFlag: I have try to do a make menuconfig, but seems I have removed too much : don't finish the boot... |
| 22:22:00 | fontenot | PuckCh: I read on arm list that kernels built with gcc3 dont work right |
| 22:22:17 | fontenot | dunno if that has been fixed |
| 22:22:42 | fontenot | both of your problems are because you are using gcc3 to build the kernel |
| 22:23:17 | PuckCh | yes. and also now uClibc don't build. :-( |
| 22:23:29 | PuckCh | arm-linux-ld: ./tmp/libgcc-need.a(_divsi3.o): Relocations in generic ELF (EM: 0) |
| 22:23:34 | PuckCh | grrrr.... |
| 22:23:48 | PuckCh | ./tmp/libgcc-need.a(_divsi3.o): could not read symbols: File in wrong format |
| 22:23:58 | fontenot | PuckCh: any way you can use a 2.95.3/4 based toolchain instead? |
| 22:24:19 | PuckCh | fontenot: i think so too. |
| 22:24:40 | PuckCh | I will start now making a 2.95 toolchain. |
| 22:26:00 | fontenot | ibot: search for blundell |
| 22:27:09 | fontenot | PuckCh: make sure you either use debian gcc source or add the Phil Blundell ARM patch to your gcc |
| 22:27:49 | PuckCh | fontenot: I will use the debian gcc source. Thanks for the tip. |
| 22:28:06 | fontenot | np |
| 22:36:41 | PuckCh | ok. I allready have a home-made 2.95.3 toolchain installed. will try it now. |
| 22:37:33 | PuckCh | the 3.0 was made with toolchain-source debian package. Easy to make, but not really OK for me now. |
| 22:58:02 | PuckCh | cool : 905364 Mar 30 23:50 tuxscreen-kernel |
| 22:58:07 | PuckCh | flashed and booting OK |
| 22:58:27 | BZFlag | added make source |
| 22:59:44 | PuckCh | I think I know why the kernel I have made with 3.0 don't boot : i was removing FAT fs |
| 23:00:24 | PuckCh | I was thinking FAT fs is only for dos/win$ows |
| 23:01:47 | PuckCh | is FAT fs used for booting on Tux ? |
| 23:01:50 | BZFlag | you should not need fat fs |
| 23:02:37 | PuckCh | ok, so I was right. but why the boot say : FAT: bogus logical sector size 381 |
| 23:03:06 | BZFlag | ignore that. |
| 23:03:30 | BZFlag | hmm... if fat/vfat/msdos/umsdos are all removed, you should not get that message. |
| 23:03:49 | PuckCh | the message before (shannon_pcmcia_configure_socket(): Warning, Can't perform reset) was the last I saw with my 3.0 |
| 23:04:18 | PuckCh | but, now I don't have removed it. |
| 23:08:10 | PuckCh | the ramdisk image was also done correctly. All my problems was due to the 3.0 compiler. |
| 23:10:08 | fontenot | yep |
| 23:10:45 | PuckCh | is someone here using PicoGUI with his Tus ? |
| 23:10:55 | PuckCh | s/Tus/Tux/ |
| 23:11:04 | fontenot | some ppl are |
| 23:11:07 | fontenot | not me |
| 23:11:26 | fontenot | i am not sure if buildroot with pico is working right now |
| 23:11:36 | fontenot | i heard microwindows was |
| 23:12:04 | PuckCh | yep, buildroot has both microwindows and picogui. |
| 23:12:27 | PuckCh | just, the touchscreen with PicoGUI don't work correctly. |
| 23:12:55 | fontenot | ok |
| 23:17:14 | BZFlag | pico does not build for me |
| 23:20:40 | PuckCh | i will try again now, but I don't remember of any problems for the build |
| 23:22:48 | PuckCh | strange : it has used cc for compiling mtd... |
| 23:23:12 | PuckCh | is this the reason of :jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 0x8519 instead |
| 23:23:19 | PuckCh | during the boot |
| 23:23:39 | PuckCh | (of course, the boot don't finish with this) |
| 23:24:55 | PuckCh | and the pico is not building right now with the last cvs |
| 23:25:44 | PuckCh | it use build/stage/usr/bin/arm-uclibc-gcc, but the compiler is build/staging_dir/usr/bin/arm-uclibc-gcc |
| 23:33:13 | BZFlag | it's stale. |
| 23:33:32 | BZFlag | rm -r build/picogui |
| 23:34:50 | PuckCh | I don't have a picogui dir at this time (1st try on this machine) |
| 23:35:02 | PuckCh | the problem in in the jpeg-6b dir |
| 23:35:17 | PuckCh | rm -r build/jpeg-6b don't correct the problem. |
| 23:40:40 | PuckCh | hummm... seem it's the uClib installation : one part in stage, one part in staging_dir. Trying rm -r build/uClibc |
| 23:50:16 | andersee | BZFlag: k, most of my private testing stuff is now merged in... |
| 23:52:36 | PuckCh | why mtd |
| 23:52:50 | PuckCh | sorry. why mtd-20011217 is build with cc ? |
| 23:52:56 | andersee | should write a small newt based phone app, since nobody around here can seem to make a gui work consistantly... |
| 23:53:21 | andersee | PuckCh: because mkfs.jffs2 runs on the host system, not the phone |
| 23:53:40 | PuckCh | hoops.. ok. sorry. |
| 23:58:37 | scanline | is back (gone 15:00:21) |