| 00:01:10 | CosmicPenguin | is away: Uh, oh.. the weasel got out again... |
| 00:17:51 | TomW | is back (gone 02:43:14) |
| 00:25:00 | GPSFan | TomW: you about? |
| 00:25:31 | TomW | about what? I'm confused today, too much sleep last night. :-) |
| 00:26:46 | GPSFan | you said you wanted sleep, now you have too much! ;>) got my SODIMMS, I had to cover up pin 71, but without mods to blob they show up as 16M. |
| 00:28:22 | TomW | GOOD! Cut the trace on pin 71 (or any GNDs found on pins 11, 69, 70 or 71). Cuttin the trace on the SODIMM will only make it unusable in a laptop / notebook. |
| 00:28:33 | TomW | What partnumber is on the chips on the SODIMM? |
| 00:29:10 | TomW | BTW, if it boots with only pin 71 covered, you found them all. |
| 00:29:42 | GPSFan | the trace to pin 71 is easily accessable, the hcips are chip-scale parts and don't have #'s. I rang out all the prd's first, 71 was the only one that mattered. |
| 00:30:48 | TomW | Ok, if you change blob MDCNFG from xxxxxx1F to xxxxxx3f and only get 16Meg from the device, then it is an 8K refresh (13x9 organization). |
| 00:31:52 | GPSFan | the module p/n is 56RW832DZJ-6LS/C I'll be doing a few searches for it to see if I can find any info. |
| 00:32:47 | byron | hello all .. been having trouble getting nano-x to work on tuxscreen .. narrowed the errors down to: 'error 2 opening touch panel' and ' cannot initalise mouse' .. any ideas on this? |
| 00:33:21 | sjm | byron: kernel version? microwin snapshot version? |
| 00:34:13 | byron | 2.4.18-rmk2-tux1 .. and .. latest microwin with patch from tuxcreen download |
| 00:34:36 | TomW | Just change blob, if it is a 13x9 (8K refresh) there is nothing that you can do to it to get it to give you more rows. I suspect very strongly that if you got the 16Meg on it with the stock blob, then it is 4K refresh. IMO a 32M device that is 8K refresh would only give 8M total ram with the stock blob. |
| 00:35:36 | GPSFan | TomW: we'll see, I'm figureing out the blob command to change MDCNFG now. |
| 00:35:47 | TomW | byron: you have to get shared libs working and set the configuration file src/blob/config to the correct mouse & keyboard. wait one while I check my config. |
| 00:36:32 | byron | TomW: roger that =) |
| 00:37:45 | TomW | byron: sorry I meant microwin/src: |
| 00:37:48 | TomW | GPMMOUSE = N |
| 00:37:48 | TomW | SERMOUSE = N |
| 00:37:48 | TomW | TPMOUSE = N |
| 00:37:49 | TomW | TPHELIO = N |
| 00:37:49 | TomW | ADSMOUSE = N |
| 00:37:49 | TomW | IPAQMOUSE = N |
| 00:37:51 | TomW | HARRIERMOUSE = N |
| 00:37:53 | TomW | PSIONMOUSE = N |
| 00:37:55 | TomW | MTMOUSE = N |
| 00:37:58 | TomW | NOMOUSE = N |
| 00:38:00 | TomW | UCB1X00MOUSE = Y |
| 00:38:02 | TomW | # keyboard or null kbd driver |
| 00:38:04 | TomW | TTYKBD = N |
| 00:38:06 | TomW | SCANKBD = Y |
| 00:38:08 | TomW | PIPEKBD = N |
| 00:38:10 | TomW | NOKBD = N |
| 00:38:13 | TomW | byron: you want my config file to look at? I can DCC it to you? |
| 00:38:37 | byron | TomW: that would be great .. please send |
| 00:39:28 | TomW | sending now. |
| 00:40:26 | byron | Tomw: will this get the shared libs to work? |
| 00:41:39 | TomW | there were a number of changes I had to do to microwin to get it to work. BTW. the microwin from buildroot wget doesn't work. I used the one that someone turned me onto from Alex Holden's site, sorry dont have the url. |
| 00:41:53 | TomW | sjm: there? |
| 00:42:25 | byron | TomW: roger that .. have seen several references in the wiki on that site, but no url is listed |
| 00:45:13 | byron | TomW: please resend config file .. was not setup correctly earlier |
| 00:53:43 | TomW | brb |
| 00:57:15 | sjm | byron: sorry - hazarads of irc'ing at work :) |
| 00:57:44 | sjm | byron: grab http://www.linuxhacker.org/mw/microwin-aph-11feb2002.tar.gz |
| 00:58:43 | sjm | byron: once it's built, you'll probably need to cp microwin/src/lib/*.so to root/lib |
| 01:02:20 | byron | sjm: excellent .. will go get it now =) thank you |
| 01:18:03 | BZFlag | GPSFan: you will need to rebuild blob. changing mem timings at the blob prompt will not force blob to rescan memory. |
| 01:19:14 | BZFlag | byron: patches to buildroot welcome. ;-) |
| 01:29:29 | GPSFan | BZFlag: yep, just found that out, rebuilding now, but probably will be delayed by dinner ;>) |
| 01:31:06 | BZFlag | GPSFan: with the blob change the kernel will not boot. |
| 01:31:18 | BZFlag | so test, then reinstall a normal blob. |
| 01:32:34 | Russ|werk | andersee about? |
| 01:34:19 | | andersee was last seen on #tuxscreen 12 hours, 41 minutes and 31 seconds ago, saying: Morning sjhill [Wed Apr 3 13:52:48 2002] |
| 01:34:19 | BZFlag | ibot: seen andersee |
| 01:35:16 | Russ|werk | bummer |
| 01:35:31 | Russ|werk | his ptheads implemtation is notably lacking |
| 01:36:25 | Russ|werk | and there are any semaphores like he said there was... |
| 01:37:50 | GPSFan | TomW: just changed MDCNFG to xxx3f and blob's memory map has 8 2M chunks instead of 4 4M chunks. |
| 01:38:34 | GPSFan | TomW: of course Linux doesn't boot. |
| 01:44:49 | GPSFan | but if I change mdcnfg to xxx2f I get 2 16M chunks, and 8 1M chunks |
| 01:45:02 | Russ|werk | you need a 4M chunk at 0xc0000000 |
| 01:45:16 | Russ|werk | or you need to work with the decompressor, and initial MMU setup |
| 01:45:25 | TomW | byron: you set with sjm & the Alex Holden stuff? |
| 01:45:42 | GPSFan | Russ: to get linux to boot, yes. |
| 01:46:02 | TomW | byron: BTW, that config file was from the Alex's files. |
| 01:46:18 | Russ|werk | GPSFan: modifing the kernel to boot with 1M chunks doesn't look that difficult though |
| 01:47:01 | TomW | looks like I will be teaching a newbie linux Adult Education course at the local VoTech. |
| 01:48:31 | GPSFan | Russ: I think someone looked at this before, and wound up patching the kernel to boot Linux at 0xd0000xxx. |
| 01:48:37 | TomW | GPSFan: did you upgrade the blob from 2.0.4 to 2.0.5-pre3 in the process? |
| 01:48:55 | GPSFan | TomW: I'm using 2.05-pre2. |
| 01:49:12 | Russ|werk | GPSFan: ya, that was a broken solution |
| 01:49:28 | GPSFan | Russ: yes I know |
| 01:50:04 | TomW | GPSFan: this the version that was on the Tux before the RAM change & blob mods? |
| 01:51:00 | GPSFan | TomW: yes, I hve one of my tuxes at 2.0.5-pre-2 and the other one at 2.0.4. |
| 01:53:26 | TomW | GPSFan: this is my blob memory report and I can program the kernel & ramdisk and boot linux: |
| 01:53:28 | TomW | Memory map: |
| 01:53:29 | TomW | 0x01000000 @ 0xc0000000 (16 MB) |
| 01:53:29 | TomW | 0x01000000 @ 0xc8000000 (16 MB) |
| 01:53:29 | TomW | 0x00100000 @ 0xd0000000 (1 MB) |
| 01:53:29 | TomW | 0x00100000 @ 0xd0400000 (1 MB) |
| 01:53:31 | TomW | 0x00100000 @ 0xd0800000 (1 MB) |
| 01:53:33 | TomW | 0x00100000 @ 0xd0c00000 (1 MB) |
| 01:53:35 | TomW | 0x00100000 @ 0xd8000000 (1 MB) |
| 01:53:37 | TomW | 0x00100000 @ 0xd8400000 (1 MB) |
| 01:53:39 | TomW | 0x00100000 @ 0xd8800000 (1 MB) |
| 01:53:41 | TomW | 0x00100000 @ 0xd8c00000 (1 MB) |
| 01:54:02 | TomW | GPSFan: that is a modified Tux, 32M on the mainboard. |
| 01:54:30 | GPSFan | TomW: mine is just the opposite, the 1M chunks start at 0xc000xx and the 16M chunks at 0xd000xx |
| 01:55:25 | GPSFan | TomW: this is to be expected, it looks just like the Crucial module except it has a different row address bit count. |
| 01:55:34 | TomW | GPSFan: what does your blob map look like? I am interested as to what the 2f setting did. |
| 01:56:11 | GPSFan | TomW: I can't paste it since I'm on another machine for IRC |
| 01:57:03 | GPSFan | TomW: mine is just the opposite, the 1M chunks start at 0xc000xx and the 16M chunks at 0xd000xx |
| 01:58:58 | TomW | What address are the 0xdxxxxxxx regions (both of them)? |
| 01:59:23 | GPSFan | 0xd000000000 0xd8000000 |
| 02:01:08 | GPSFan | that is 0xd0000000 (16M) 0xd8000000 (16M) |
| 02:01:33 | byron | TomW: well still get undefined reference errors =) but only on kbddev and mousedev in the libmwengine.so |
| 02:04:50 | TomW | byron1: just for giggles, try this tree. |
| 02:05:32 | TomW | byron1: ... or diff it against the one you have. I know that I had to make changes, but don't recall what they were. |
| 02:06:48 | byron1 | TomW: ok =) |
| 02:06:49 | GPSFan | TomW: what if we swap the RAS signals between the on-board mem and the SODIMM, wouldn't that swap the regions? |
| 02:07:46 | TomW | GPSFan: the mainboard RAM is coming in at 0xc000:0000, 0xc040:0000 0xc080:0000 ... at 1 meg chunks? |
| 02:08:40 | GPSFan | mainboard at 0xc0 0xc02 0xc04... correct. |
| 02:10:17 | TomW | GPSFan: ah! it is coming in on 2Meg boundries, not 4Meg boundries. Note that my boundries for the 8Meg SODIMM were on 4Meg boundries? |
| 02:10:54 | GPSFan | you are right!! |
| 02:11:25 | TomW | 9 bit rows. |
| 02:11:37 | GPSFan | maybe I'll have to ger xirc running so I can paste stuff directly. |
| 02:11:40 | TomW | Your DIMM is 8k refresh |
| 02:12:19 | TomW | ... have to think this more. |
| 02:18:02 | jacques_gone | hi ho |
| 02:20:02 | TomW | I am considering whether the lower RAM field address & the SODIMM address space can be swapped by reprogramming within blob. |
| 02:22:10 | byron1 | TomW: may have missed a message .. which tree? |
| 02:25:35 | jacques | hmm time to read scrollback |
| 02:25:52 | TomW | byron1: Had to rerun X, somehow it screws up the keyboard so I can't type anything. It has something to do with the mouse. |
| 02:26:39 | TomW | byron1: this tree (dcc) |
| 02:27:07 | byron1 | TomW: awesome .. will give it a shot |
| 02:27:25 | TomW | byron1: there were changes I did to files, don't recall what exactly. Oh, you have to remove the nxscribble dir, otherwise it won't compile. |
| 02:27:50 | byron1 | TomW: ok, thanks |
| 02:28:06 | TomW | I did something else, but don't recall. I don't think I had to change the buildroot/Makefile ... but. |
| 02:41:24 | TomW | Something does not make sense on the Tux DRAM schematics. According to the schematics: the mainboard READ DATA output is controlled by #0E, the SODIMM READ DATA output buffers are gated on by #CS1. That does not make sense as when the CSx is active, isn't #OE also active? |
| 02:44:45 | TomW | That pinout of the SODIMM can't be correct. |
| 02:53:41 | TomW | Schematic is correct. :-( |
| 02:58:11 | TomW | GPSFan: the SA-1100 datasheet that I have does not cover the operation / theory behind the CSx (Chip Selects), nor does it go in to any detail about the operation of the DRAM controller (except to explain the MDCASx shift register). |
| 03:03:04 | TomW | GPSFan: It would seem to me that if you wanted to rework the CPU board to swap the SODIMM & main DRAM memory locations, you would do that by swapping the CSA0 + CAS2 with CAS1 + CAS3 and #OE with #CS1. This is not an option (hardware hacking) as they are using a 6 layer PCB. |
| 03:03:45 | TomW | BZFlag: were you able to boot your tux with the 32M SODIMM installed (not the 64M)? |
| 03:03:53 | byron1 | TomW: compiled great and image shows promise .. thank you again =) |
| 03:05:12 | GPSFan | TomW: back from dinner. why not change the RASs since they control which physical bank is which? |
| 03:07:04 | TomW | Darn it! That SA-1100 manual is crap, it doesn't give enough info on the processor, looks more like some engineers' cheat-sheet! |
| 03:07:11 | TomW | I dunno. |
| 03:07:52 | TomW | Does the Tux that BZFlag has the 32M SODIMM installed in it boot & operate okay (program kernel, etc)? |
| 03:10:00 | TomW | what do you get when the blob is programmed for 3f? |
| 03:38:00 | TomW | GPSFan: can you give the the output from blob? |
| 03:40:35 | GPSFan | TomW: not right now, I have things torn apart, but from memory, the 1M chunks started at 0xc, and the 2M chunks started at 0xd. more details I won't have till I put it all back together. |
| 03:41:10 | TomW | Ok, I need to see those addresses so that I can confirm what is going on. |
| 03:41:28 | TomW | I will be here for a few more hours, no problem. |
| 03:42:13 | TomW | Just wish that I had my SODIMMs here, but I only ordered them Monday and they shipped tham Parcel Post. |
| 03:53:04 | BZFlag | TomW: 32m booted fine, but with normal blob just looked like a 8M |
| 03:53:22 | BZFlag | 64M with 11 blocked looks like a 16M |
| 03:54:50 | TomW | tnx |
| 03:55:28 | TomW | GPSFan has his new SODIMM and I strongly suspect it is a 13x9 (8K refresh). |
| 03:57:23 | BZFlag | the 8k refresh that crucial sells does not boot. could be the same pin 71 mod required, don't know. |
| 03:58:21 | BZFlag | so I've got: Mem: 22679552 in /proc/meminfo |
| 03:58:58 | TomW | GPSFan found the pin 71 was tied to gnd on his sodimm, once he cleared the short it booted. |
| 03:59:01 | BZFlag | and from dmesg: Memory: 4MB 4MB 4MB 4MB 4MB 4MB = 24MB total |
| 03:59:01 | BZFlag | Memory: 22080KB available (1689K code, 296K data, 68K init) |
| 04:00:28 | BZFlag | TomW: does your dmesg | grep Memory: show 16,16,1,1,1,1,1,1,1,1 ? |
| 04:01:57 | TomW | yes |
| 04:02:20 | TomW | .. well wait ... brb |
| 04:09:05 | TomW | # dmesg | grep Memory |
| 04:09:05 | TomW | Memory: 16MB 16MB 1MB 1MB 1MB 1MB 1MB 1MB = 38MB total |
| 04:09:05 | TomW | Memory: 36140KB available (1729K code, 304K data, 72K init) |
| 04:09:17 | GPSFan | BZFlag & TomW: well, I swapped RAS0 & RAS2 I now have 16M as the first chunk at 0xc0000000 followed by 8 1M chunks at 0xc8000000, 0xc82000000 0xc84000000.... followed by a 16M chunk at 0xd8000000, Linux boots with 24 meg... |
| 04:10:35 | GPSFan | looks like the max # of chunks problem, but swapping RASs moves the banks around. |
| 04:12:46 | TomW | I still cannot fathom why the DRAM is being mapped out by the processor into 1M chunks at 2M boundries. |
| 04:13:32 | TomW | I know why the RAM is at 1M chunks, just not why the 2M boundries. |
| 04:15:32 | GPSFan | TomW: if I swap the other 2 RASs, it will put the other 16M bank at 0xc8000000 so my map will sort of match yours. |
| 04:19:55 | GPSFan | BZFlag: is there a kernel option to have more than 7 regions? |
| 04:20:10 | GPSFan | s/7/8 |
| 04:28:09 | BZFlag | what did you have to do to swap RAS0 & RAS2 ? |
| 04:29:03 | GPSFan | the handy 56 ohm resistors on the back of the main board make it relatively easy. They are in series with tha RAS CAS & control lines. |
| 04:29:14 | BZFlag | TomW: blob takes the first memory alias it finds and discards the rest. those areas likely map to many places. build blob with mem-debug and it will dump all of them as on: |
| 04:29:37 | BZFlag | http://TuxScreen.net/wiki/view/InfernoSODIMM |
| 04:33:16 | BZFlag | GPSFan: now you have a phone that will not boot without that larger sodimm in it, right? |
| 04:35:21 | GPSFan | BZFlag: correct, especially since I changed blob to support that SODIMM. but blob does come up. |
| 04:36:48 | BZFlag | GPSFan: change NR_BANKS in include/asm-arm/setup.h |
| 04:37:27 | TomW | I'm back, was ragchewing with a couple of Ham buddies. |
| 04:38:14 | GPSFan | BZFlag: this may not be the solution to our memory issues, but is research. Also my SODIMM cost $7.00. Just putting it in with no changes but tape on pin 71 gets 24M (8 on board + 16) |
| 04:38:18 | BZFlag | blob should work as long as there is 1M at c000 |
| 04:38:51 | BZFlag | but you can't boot with that 24M right? |
| 04:38:54 | GPSFan | BZFlag: blob's map shows the first region at 0xc8000000 |
| 04:39:33 | BZFlag | huh?!? there should be somthing at c0000000, no? |
| 04:39:37 | TomW | GPSFan: that should work, I didn't realize that it would be that convenient to swap those lines. I would suggest that you use 56ohm resistors as jumpers instead of just jumper wire. You do need that small resistance there to properly shape the rise/fall times on those signals. |
| 04:39:51 | GPSFan | BZFlag: yes, that 24M boots fine, the SODIMM just looks like 16 instead of 32. |
| 04:40:26 | BZFlag | GPSFan: ahh, so you have the 6 4M regions I have, yes? |
| 04:40:45 | GPSFan | TomW: yes, I know why the resistors are there, and will if I make this permanant. |
| 04:41:08 | TomW | GPSFan: ok, didn't know your level of expertise in electronics. |
| 04:41:33 | GPSFan | BZFlag: with the original config, yes, 4 + 4 onboard and 4 +4 +4 +4 on the SODIMM |
| 04:41:40 | TomW | boiling water for tea. |
| 04:42:37 | GPSFan | BZFlag: so with nothing but a piecce of tape and $7.00 you can upgrade any tux to 24 useable Megabytes. |
| 04:42:38 | TomW | GPSFan: how is blob configured? 1f, 2f, 3f? |
| 04:42:57 | GPSFan | TomW: right now it is 2f |
| 04:43:04 | jacques | 24 is good. 40 is much better. |
| 04:43:14 | TomW | 64 is better. |
| 04:43:21 | jacques | 64 is excellent |
| 04:43:25 | GPSFan | 128 even morebetter |
| 04:43:28 | TomW | BZFlag: right Tim? |
| 04:43:33 | jacques | 128 is delirious |
| 04:43:44 | GPSFan | 256 would be yummy |
| 04:43:48 | TomW | BZFlag: ... at least we hope we get it. |
| 04:44:02 | TomW | That 128 may be possible to do... |
| 04:44:32 | GPSFan | I think 24 is easy for anybody, 38, for many, 64, for few. |
| 04:44:45 | jacques | why is it 38 sted 40 ? |
| 04:45:43 | TomW | Swap the signals as GPSFan has done, then use the SODIMM connector to take the needed signals up to a 128M 72pin SIMM that is mounted on the metal shield inside the Tux. |
| 04:46:15 | TomW | The SODIMM connector has all the appropriate signals to handle 128Meg. |
| 04:46:52 | TomW | ... gotta check on that to see how may RAS lines would be needed on a 128M part. |
| 04:47:19 | jacques | i need at least a much ram as my 32MB ipaq |
| 04:48:46 | GPSFan | jacques: 38 if we don't find a way to let Linux have more than 8 regions. 40 if we do with the same hardware hack, ie swap the RAS0,1 with RAS2,3 |
| 04:50:03 | GPSFan | 64 with a Crucial/Coast-Coast SODIMM @ $30.00 +4 x $7.35 plus a lot of smt rework. |
| 04:56:52 | TomW | Do they make a 72pin 128meg part? I quickly find a datasheet on that SIMM module. |
| 04:58:28 | jacques | GPSFan: ah. I wonder why the 8 region max |
| 04:58:59 | Sammy | andersee: how to define baud rates at tinylogin ? |
| 04:59:24 | TomW | So that the MMU has free entries to map user processes. It is a tradeoff of MMU utilization. |
| 04:59:27 | BZFlag | GPSFan: to get more regions, change NR_BANKS in include/asm-arm/setup.h |
| 05:00:03 | jacques | TomW: wow I had no idea it was a hardware limitation |
| 05:00:05 | TomW | I think that the ARM MMU only has 32 entries? |
| 05:00:22 | BZFlag | TomW: largest 72 pin sodimm I can find is the 64M I have. |
| 05:01:09 | TomW | No, not hardware. It is a decision by the linux-arm people. IIRC, the pentium processors have at least 64 table entries in their MMU and ARM only has 32 table entries. |
| 05:01:51 | jacques | well 32 is a lot more than 8 - what am I missing? |
| 05:02:07 | TomW | If you decrease the number of free entries, IMO, your linux would spend more time swapping out table entries. this would slow things down. |
| 05:02:35 | GPSFan | BZFlag: thanks , we would only be increasing it to 10. |
| 05:02:37 | BZFlag | Sammy: in /etc/inittab I have: ttySA0::respawn:/sbin/getty -L ttySA0 115200 vt100 <- change the 115200 to what you like. |
| 05:02:44 | TomW | 8 fixed entries for RAM, the other 24 are for processes. |
| 05:03:10 | jacques | 10/22 does not sound significantly worse |
| 05:03:37 | TomW | someone correct me if I am wrong, I have been hacking the kernel for only two years and I haven't gotten too deeply into MMU theory... |
| 05:03:51 | GPSFan | if we went to 10 entries, we would only have to swap RAS0 & RAS3 |
| 05:04:05 | BZFlag | TomW: off hand I can confirm or dispute it, so keep talking. ;-) |
| 05:04:11 | BZFlag | er can't.... |
| 05:09:34 | BZFlag | sboot tests for different memory configs and adjusts. we could build a blob that did the same. ie: runs with 3f if needed and 1f if not. |
| 05:09:59 | BZFlag | the issue is that the kernel would not run in the 3f config on the base board cause of fragmentation. |
| 05:10:29 | BZFlag | so if blob detected a 32M sodimm and switched to 3f the kernel would (does) hang on decompressing. |
| 05:11:07 | BZFlag | anyone fixed either mw or pico in buildroot to run with the current ts code? |
| 05:11:32 | BZFlag | has a nice picogui startup screen on his phone now, but can't use the touchscreen. |
| 05:11:57 | jacques | i thought mw was running with current ts |
| 05:12:03 | jacques | but havent tested it |
| 05:14:31 | BZFlag | would strongly prefer a working tinyx in buildroot.... |
| 05:15:41 | jacques | i am so disgusted with xfree right now |
| 05:16:06 | jacques | the ts stuff in cvs after 10-10 of last year seems to be totally broken |
| 05:16:25 | jacques | i wasted about 1.5 days on it beofre i figured that out |
| 05:16:59 | jacques | and the breakage runs deep |
| 05:17:04 | TomW | well, I'll call coast-to-coast memory in the morning and see if they have 128Meg 72pin EDO SIMMs. Would be nice to crank a tux up to 128M, maybe install that 10G laptop drive in it as well? |
| 05:17:10 | jacques | it's in the new *mi stuff |
| 05:17:44 | jacques | TomW: think the pcmcia 5V mod would handle enough current? |
| 05:18:19 | jacques | i have a 20GB 2.5" drive attached to my ipaq |
| 05:18:27 | jacques | through the pcmcia sleeve |
| 05:18:33 | jacques | would like that on the tux |
| 05:19:23 | TomW | BZFlag: the MMU is used to remap regions of memory to a different location. We would need to remap the TUX Flash & DRAM locations to an area that is fixed in the Linux-arm map. The DRAM goes low, starting a 0x00000000, the flash memory goes to someplace else. So we would use 8 for the DRAM + 1 for the flash. |
| 05:19:54 | TomW | jacques: yeah, but, that takes up both slots right? (Type II) |
| 05:20:43 | jacques | TomW: nope - I have a pcmcia -> 2.5" IDE adaptor |
| 05:21:07 | jacques | TomW: and use a regular 2.5" notebook drive - much cheaper than the pcmcia drives |
| 05:21:07 | TomW | :-) |
| 05:21:30 | jacques | it works great on the ipaq and is much faster than th microdrive |
| 05:21:45 | jacques | (not to mention 20x bigger and much cheaper) |
| 05:22:31 | TomW | well, it is getting late for me: tomorrow I have people to do and places to see... |
| 05:23:04 | jacques | TomW: dont get too much sleep - remember what happened last night |
| 05:23:07 | TomW | ... and maybe, my 32M SODIMMs will be here (I hope, I hope). |
| 05:23:13 | BZFlag | TomW: there are io maps as well. |
| 05:23:19 | TomW | yes 9 hours. |
| 05:25:21 | TomW | BZFlag: Yes, we still need TLB entries for the linux + user processors. The MMU is the key in providing multi-user (process) memory isolation. So, we could conceivably soak up as manny as 12 (or more) TLB entries just on the hardware. Thus only leaving 18 entries for linux + process management. |
| 05:26:35 | TomW | There wouln't be any reason *not* to increase the TLB entries set aside for the DRAM, just that you could pay a heavy performance penalty elsewhere. |
| 05:27:12 | TomW | you can tell that I am tired, beginning to speel bahdly. |
| 05:27:21 | TomW | later |
| 05:27:32 | TomW | is away: sawing wood. |
| 05:31:01 | GPSFan | BZFlag: incase you are interested, this is where I got my SODIMMs http://www.computersurplusoutlet.com/viewproduct.asp?ProductID=MEM-SO32E7 |
| 05:32:48 | BZFlag | add the link to the wiki sodimm page. |
| 05:33:02 | GPSFan | you bet, |
| 05:33:29 | jacques | $7 for 16MB is not bad |
| 05:33:45 | jacques | but i gots to have at least 32MB :-( |
| 05:40:26 | jacques | this memory research is exciting |
| 05:40:47 | jacques | if we can get cheap 32-40MB I am going to buy more tuxes :-D |
| 05:43:58 | BZFlag | 40M should just involve changing the kernel decompressor. |
| 05:44:21 | jacques | 38 would be good enough for me |
| 05:45:31 | BZFlag | no hw mods. you can see 8 1m + 2 16M chunks with your without mods, yes? |
| 05:45:56 | GPSFan | BZFlag: correct. |
| 05:46:21 | GPSFan | BZFlag: just the change to blob & a piece of tape. |
| 05:46:22 | BZFlag | swapping onboard memory will get us to 32+32 with no sw changes. |
| 05:47:06 | jacques | GPSFan: ?? I thought you were only getting 24MB ? |
| 05:47:26 | BZFlag | well, ok with the blob change to 3f (or 3f) |
| 05:47:31 | BZFlag | er or 2f |
| 05:47:33 | TomW | is back (gone 00:20:01) |
| 05:47:40 | jacques | ? |
| 05:47:42 | GPSFan | blob sees it all, Linux only can see 24 with the hardware mod and 8 regions. |
| 05:48:12 | jacques | GPSFan: ah that's why you were talking about swapping some order? because one of the 16MB regions is not being seen? |
| 05:48:17 | jacques | by linux |
| 05:48:24 | GPSFan | changing both RASs should get you 38, |
| 05:48:30 | BZFlag | with the on board memory rework that TomW did, there should be 4 16M regions with blob set to 3f and the 32M sodimm. |
| 05:48:33 | jacques | whooo! |
| 05:48:49 | GPSFan | 16 +16 +1 +1 +1 +1 +1+ 1 |
| 05:49:10 | jacques | heh I am not getting my hopes up about evre getting the onboard chips changed on my tuxes - I am looking for a 32MB off-board solution now |
| 05:49:53 | BZFlag | with blob and kernel changes you can run the kernel at 0xd0000000 now and have 32M |
| 05:49:54 | TomW | # dmesg | grep Memory |
| 05:49:54 | TomW | Memory: 16MB 16MB 1MB 1MB 1MB 1MB 1MB 1MB = 38MB total |
| 05:49:54 | TomW | Memory: 36140KB available (1729K code, 304K data, 72K init) |
| 05:49:57 | TomW | # dmesg | grep Memory |
| 05:49:57 | TomW | Memory: 16MB 16MB 1MB 1MB 1MB 1MB 1MB 1MB = 38MB total |
| 05:49:57 | TomW | Memory: 36140KB available (1729K code, 304K data, 72K init) |
| 05:50:05 | TomW | oops. |
| 05:50:29 | TomW | jacques: that is with the mainboard 32M upgrade. |
| 05:50:31 | BZFlag | TomW: try the NR_BANKS next? |
| 05:50:31 | jacques | GPSFan: so theoretically we can get 38-40MB with your $7 sodimm ? that rocks |
| 05:51:21 | GPSFan | jacques: 40 only if you are willing to change NR_BANKS to 10 and take the consequences (what ever they may be) |
| 05:51:55 | jacques | GPSFan: but 38 is easier? |
| 05:52:01 | jacques | 38 is enough for me |
| 05:52:10 | jacques | esp for $7 |
| 05:52:12 | BZFlag | I think more memory will be worth whatever the impact of changind NR_BANKS is |
| 05:52:19 | TomW | jacques: we are hoping to get 64Meg with the mainboard mod + a 32Meg SODIMM. |
| 05:52:35 | BZFlag | perhaps 64+64 even. ;-) |
| 05:52:41 | GPSFan | for 64 you shouldn't need to change NR_BANKS |
| 05:52:49 | TomW | are |
| 05:52:51 | jacques | TomW: that's excellent, but I am a smt-challenged individual |
| 05:53:08 | TomW | are you good at soldering regular stuff? |
| 05:53:25 | scanline | is back (gone 06:37:00) |
| 05:53:32 | BZFlag | jacques: with sw you can get 32 by ignoring the onboard memory. |
| 05:54:15 | TomW | jacques: can you solder? |
| 05:54:57 | jacques | TomW: yeah I can solder but smt scares me -- too tiny |
| 05:55:15 | jacques | i need to get a scope too |
| 05:55:22 | TomW | look at the bottom of this page: http://TuxScreen.net/wiki/view/32MegRamUpgrade |
| 05:55:50 | TomW | it is for the "SMT Challenged". |
| 05:55:53 | jacques | yeah weller 40W pencil - that takes lots of skill |
| 05:56:00 | TomW | ?? |
| 05:56:05 | jacques | to do smt with it |
| 05:56:21 | TomW | many people use that technique |
| 05:56:26 | jacques | i have a reasonable nice hakko |
| 05:56:39 | jacques | temp adjustable |
| 05:56:51 | jacques | i need to find some solder wick tho |
| 05:56:55 | TomW | yuk! I passed one of those by when I was looking for SMT rework gear. |
| 05:57:05 | jacques | you dont like them? |
| 05:57:09 | jacques | i like mine |
| 05:57:25 | jacques | it's a soldering iron - not the smt rework unit |
| 05:57:45 | TomW | The thing that I didn't like was the amount of heat they threw at the board. It would be too easy to de-laminate the board with that setup. |
| 05:58:03 | TomW | Oh, you like imported stuff , eh? |
| 05:58:08 | jacques | you must be talking about the smt unit - i just have a temp adjustable iron |
| 05:58:31 | GPSFan | jacques: 24=1 piece of tape, 38= some cuts & jumpers + blob, 40= change NR-Banks, 64= SMT work |
| 05:58:32 | jacques | it was better price than the weller at fry's and quality looked at least as good |
| 05:59:38 | GPSFan | TomW: the Hakko we had at work was able to vary the air flow as well as the temperature, it also would use Liester tips. But I had a Liester. |
| 05:59:43 | TomW | The key to SMT work is controlling the amount of heat you apply to the pads. Keeping the pads heated for too long will cause them to lift off the board. Same as with through hole only since the SMT has a smaller surface area it is easier to do. |
| 06:00:17 | jacques | GPSFan: well you sure can't beat the price of those SODIMMs you found! |
| 06:01:14 | GPSFan | jacques: ymmv, the ones I got were identical, since they are a surplus outfit, they may not have the same ones on any given day. |
| 06:01:30 | jacques | GPSFan: hmmm :-\ |
| 06:02:30 | jacques | GPSFan: so ones I get may not work at all... |
| 06:02:43 | GPSFan | I was willing to risk the $14.00 to find out if they would be useable, it looks like they may be, with a little effort. I don't think that they will work with TomW's main board mod though. |
| 06:03:21 | GPSFan | jacques: hard to say, you might call and see if they have lots, or just a few in stock. |
| 06:03:57 | jacques | GPSFan: ok good to know. I gues I will wait a bit to see what shakes out of all the work you guys are doing. |
| 06:04:18 | jacques | more has happened mamory-wise in the last week than in several months previous (it seems) |
| 06:04:24 | jacques | memory-wise |
| 06:05:44 | jacques | cringes waiting for mammary jokes. |
| 06:06:53 | GPSFan | time for zzzzzzzz nightall... |
| 06:07:00 | jacques | night GPSFan |
| 06:19:31 | TomW | BZFlag: still there? |
| 06:21:00 | TomW | BZFlag: how it this for an explaination of why the 64 meg SODIMM came up as only 32Meg? |
| 06:24:38 | TomW | BZFlag: blob appears to be only testing for a maximum of 32 meg of memory. Look at blob/src/blob/memory.c and then at blob/include/memory.h. The appears to be only enough space in the testing array for 32 one meg ram sections during the ram memory test. maybe all we need to do is increase the NUM_MEM_AREAS from 32 to 64. |
| 06:24:57 | TomW | BZFlag: the SA1100 is capable of a 12x11 DRAM. |
| 06:30:31 | jacques | :-D |
| 06:30:49 | TomW | lurking again, eh jacques? |
| 06:31:05 | jacques | well working and lurking |
| 06:31:05 | TomW | You just want a 96Meg Tux. |
| 06:31:20 | jacques | I will take anything I can get up to and including 256MB :-D |
| 06:31:50 | TomW | It will be interesting to see just how many megs we get out of a modified motherboard + a 64 meg SODIMM. |
| 06:31:59 | jacques | definitely |
| 06:35:03 | BZFlag | I'm happy to try the blob change on my 64 if you like. |
| 06:37:59 | BZFlag | upping regions to 64, though I'm doubtful. |
| 06:38:37 | BZFlag | I suspect that's just the number of regions, not the size and I don't have over 32 regions, just over 32M. |
| 06:39:35 | TomW | you have 64 1 meg regions. |
| 06:39:57 | TomW | ... how many chips were on that 64M SODIMM? |
| 06:40:11 | TomW | four? |
| 06:40:24 | BZFlag | 8 |
| 06:40:41 | TomW | ok, it is a 64MegByte SODIMM then. |
| 06:40:45 | jacques | dual sided? |
| 06:40:48 | BZFlag | yes. |
| 06:41:22 | TomW | The SA1100 will handle a 12x11 device, that 64Meg SODIMM is a 12x11 device. |
| 06:41:38 | jacques | i like the sound of that |
| 06:42:20 | BZFlag | so what do you want 3f? |
| 06:42:27 | BZFlag | I have 4,4,4,4,4,4 now. |
| 06:43:06 | TomW | 0x2f was the correct value for that. |
| 06:43:07 | BZFlag | 0xc0000000, 0xc8000000, 0xd0000000, 0xd0800000, 0xd8000000, 0xd8800000 with 1f |
| 06:43:14 | BZFlag | ok, trying 2f |
| 06:46:13 | TomW | I need the blob map only. |
| 06:47:39 | BZFlag | http://rikers.org/tmp/boot.txt <- with memdebug stuff included |
| 06:48:32 | BZFlag | that's with 2f |
| 06:50:22 | BZFlag | trying 3f? |
| 06:50:27 | TomW | AH! know I know why the main RAM goes to 1Meg slices. |
| 06:50:40 | TomW | no, 3f won't work. |
| 06:52:36 | BZFlag | http://rikers.org/tmp/blob3f.txt |
| 06:53:31 | TomW | that url doesn't come up. |
| 06:53:32 | BZFlag | why? |
| 06:54:01 | BZFlag | http://www.rikers.org/tmp/blob3f.txt <- if you dns servers are broken. |
| 06:55:09 | TomW | not dns it is on your end. the http server at your end is giving me an yellow triangle saying: File Not Found The requested URL was not found |
| 06:55:09 | TomW | on this server. |
| 06:55:57 | BZFlag | huh? you sure you typed it right? I just loaded it from that exact url. I tried em both. |
| 06:56:13 | TomW | dunno. |
| 06:56:20 | jacques | works for me |
| 06:56:30 | TomW | http://www.rikers.org/tmp/boot3f.txt |
| 06:57:09 | TomW | lynx on my other machine fails... |
| 06:57:16 | BZFlag | [Wed Apr 3 23:59:50 2002] [error] [client 204.186.217.33] File does not exist: |
| 06:57:16 | BZFlag | /home/groups/www/tmp/boot3f.txt wild. |
| 06:58:11 | BZFlag | ah. blob3f.txt |
| 06:58:33 | BZFlag | not boot3f.txt |
| 06:58:53 | TomW | yup, works. |
| 06:59:21 | BZFlag | wanna see a 1f for fun? |
| 06:59:48 | jacques | cut and paste is your friend |
| 07:02:08 | BZFlag | k, boot.txt -> blob2f.txt and added blob1f.txt |
| 07:02:43 | TomW | 3f won't work as it specifies a 12 ROW device is in the system, your DRAM on the SODIMM is an 11 ROW part. To select an 11 ROW device, we use 0x2f. |
| 07:06:03 | TomW | Hey! what happened to http://rikers.org/tmp/boot.txt, put it back! ;-) |
| 07:14:05 | BZFlag | heh, I moved it to blob2f.txt for consistancy. ;-) |
| 07:14:59 | | BZFlag is nothing but an off-color gob of sausage-snorfling toxic waste. |
| 07:14:59 | TomW | ibot: insult BZFlag |
| 07:15:07 | TomW | heh |
| 07:16:03 | TomW | Yes, I see now what is happening to the main memory, why it gets broken into 8 one meg chunks. |
| 07:16:13 | | BZFlag: Bad user karma. |
| 07:16:13 | BZFlag | ibot excuse |
| 07:16:54 | BZFlag | TomW: a different mapping of address pins would have fixed that in the initial design, no? |
| 07:17:34 | BZFlag | seems to me you want an 11 row mapping in all cases so that hw changes are all that's required to get to the largest possible memory config. |
| 07:18:14 | TomW | No, it is that when the 11th row is accessed (at the 2 meg boundry) the mainboard RAM (which is only 10 rows) shows the starting location of the RAM. The memory test (rightly) thinks that the RAM is only 1 meg in size. |
| 07:19:13 | jacques | configure is just a braindead piece of crap |
| 07:19:21 | TomW | When it moves up into the 3rd meg location to test, all 11 bits of the ROW address are back to zero, the new column address + row address is now valid. |
| 07:19:29 | jacques | there is no way to get it to not look in /usr/include for stuff |
| 07:19:45 | BZFlag | jacques: chroot? ;-) |
| 07:19:52 | jacques | so if one's /usr/include has wchar.h while one's uclibc/include does not, then too bad |
| 07:19:59 | TomW | BZFlag: don't warp your mind on this, it has taken me two days to understand what is happening and I have a fair amount of DRAM design. |
| 07:20:09 | jacques | *this* is why I started building things natively on my ipaq |
| 07:20:27 | jacques | BZFlag: heh maybe |
| 07:23:06 | TomW | I cannot explain, yet, what is wrong with the 64 meg module in a standard tux. BTW, we will have the same thing happen on the 32Meg modified board with a 64 Meg module. The most that you could end up with is 16 one meg slices on the mainboard and, either 4 sixteen meg slices on the SODIMM, or 2 32Meg slices on the SODIMM. |
| 07:23:07 | jacques | and this is why i want enough ram in the tux to build things natively there |
| 07:25:56 | TomW | So. The most that you could expect using the 12x11 configuration of the 64M SODIMM is either 72Meg or 80Meg, but, here is the problem, you may have as little as 12 TLB entries or as many as 20 TLB entries. |
| 07:29:06 | TomW | Either way, to use the 64 meg part you either have to increase the NUM_BANK_?? entries in linux and suffer a severe performance degradaion, or, you would do what GPSFan did, remove the resistors on the RAS0, RAS1, and #OE signals, then disable the mainboard RAM by tying those signals to 3.3volts on the RAMs. |
| 07:30:11 | TomW | That way (removal of resistors) you keep the linux performance up to where it should be and you get an easy way to increase the RAM to 64Meg. |
| 07:30:27 | TomW | provided we can get the thing working at 64Meg. |
| 07:31:08 | jacques | drool |
| 07:31:21 | TomW | jacques: behave! |
| 07:32:06 | TomW | jacques: or you'll work on windoze until *I* think you can go back to linux. |
| 07:32:12 | TomW | :-D |
| 07:33:25 | TomW | BZFlag: there may be a way to get 96Meg by adding a couple of gates to the mainboard though... |
| 07:33:41 | jacques | :-( |
| 07:33:59 | TomW | ;-) |
| 07:34:51 | TomW | BZFlag: the solution is lurking in the back of my mind someplace, I just can't pin it down yet.. It will be there in the morning, the solution usually is. |
| 07:34:52 | BZFlag | can we get 2 32M on the sodimm and 2 16M on board? |
| 07:35:52 | BZFlag | is it possible to get 64M on board? |
| 07:36:31 | BZFlag | what happens with the address pin that is mapped to pin 11? doesn't that need to go someplace? |
| 07:37:10 | TomW | that is what I am thinking. We have two 16 meg banks on the mainboard (modified). I am thinking of latching the value of the 11th row bit and using that to activate the "other" 16 meg bank. This way the mainboard RAM would appear as a single 32Meg bank, instead of the two 16 meg banks as I have now. |
| 07:39:53 | BZFlag | are all the address pins active on the ships you have onboard now? ie: there are no larger chips that might work in the exiting sockets? |
| 07:40:43 | TomW | I have to consider the RAS timing of the RAMs and if the SA1100 can vary it's RAS cycle length. If I can stretch the RAS cycle by one cycle, both during RAM access & during RAM refresh, then I could combine the two 16 meg banks into a single 32 meg bank of RAM staring at 0xc000:0000 through c1ff:ffff |
| 07:41:16 | TomW | colons are there to aid typing(!) those long nubers! |
| 07:42:51 | jacques | is that like adding a wait state? |
| 07:43:25 | TomW | Actually, now, the first 16meg (two chips x 8Megabytes per chip x 16 bits output == 16Megabyte) is on BANK0, the next two chips are tied to BANK1, this is why they show up as two seperate 16M banks and not a single 32 Meg bank. |
| 07:43:28 | BZFlag | which address lines is the 11 bit row address mapped to? |
| 07:44:35 | TomW | jacques: no, it is even more basic than that, I would need another 8..10ns longer cycle time to allow the latch to propagate the signal down to the RAS on the second bank. |
| 07:44:56 | BZFlag | er... ok in 12 bit row mode. |
| 07:44:59 | TomW | BZFlag: it is not mapped, it is hardwired. |
| 07:45:20 | BZFlag | right, on which address lines? |
| 07:45:22 | TomW | You had it right, 11th bit, 11 bit rows. |
| 07:45:57 | TomW | A21 |
| 07:46:23 | TomW | oops, it is A20. |
| 07:47:21 | BZFlag | ie: http://www.tuxscreen.net/download/schematics/dram.pdf shows A2-A21 all mapped to the sodimm socket, yes? |
| 07:49:47 | BZFlag | so is A21 active? what would happen if A21 waas disconnected from the sodimm and A9 mapped to pin 29 on the sodimm instead or pin 11 ? |
| 07:50:07 | BZFlag | s/or/of/ s/waas/was/ |
| 07:50:40 | TomW | BZFlag: I have to do some carefull thinking here. There may be other factors to consider here which I may have yet to discover. |
| 07:50:52 | BZFlag | just suggesting. |
| 07:52:53 | TomW | Too tired to think this through, like I said, the answer is lurking in my mind someplace, I can "feel" it but it isn't ready to come to the front of my mind yet. Although I may find an answer to getting 96Meg, it may be that the hardware mods to the board would be just too extensive to justify it. |
| 07:53:26 | andersee | good morning all |
| 07:54:30 | BZFlag | perhaps. from a cpu view, the system should support a max of 4 banks of 64M each. |
| 07:54:45 | jacques | andersee: hi |
| 07:55:17 | BZFlag | so with extensive board redesign it should be possible to get to 256M but as you say, the work is probably to much for the return. |
| 07:55:27 | TomW | The problem is this: I am playing a trick on the 10 row RAMs on the modified board to make the full 32 meg show up. This was done to make the devices appear as two 16 meg banks. |
| 07:56:42 | jacques | andersee: how goes the release? |
| 07:57:04 | TomW | It may be possible that my trick will fool the ARM into thinking that the 64Meg SODIMM is two banks of 16 meg as well, I suspect that this will be truly the case. |
| 07:57:07 | BZFlag | and there is no easy hack you can think of to get to twice that. |
| 07:57:37 | BZFlag | 2f or 3f get's me 2 16M banks on the sodimm now. |
| 07:58:37 | TomW | .. correct the address line wiring problem with more cuts and jumpers. It took me 5 hours to figure out where to make the 3 cuts & jumpers so that I could fool the ARM into seeing two 16meg banks. |
| 07:59:21 | BZFlag | nCS1 is wired to a12 on the sodimm so I guess that a12 is being used. |
| 07:59:40 | TomW | Once I think this through, it may be that it would be possible to have two 16 M banks in the main memory and four 16 meg banks in the SODIMM. |
| 08:00:12 | TomW | Only as a READ OUTPUT ENABLE, not as an ADDRESS line. |
| 08:00:59 | jacques | measure twice, cut once |
| 08:01:17 | TomW | Since the SA1100 doc sucks so badly, I cannot find a reason for the CS1 being used as an output enable for the 3rd & 4th RAM banks. It does make sense, but, it is not documented. |
| 08:01:26 | BZFlag | right, but the effect is similar no? |
| 08:01:36 | TomW | hey, I watch Yankee Workshop too! |
| 08:01:58 | TomW | Correct, but I don't like to *assume*. |
| 08:02:26 | TomW | andersee: morning Erik. |
| 08:03:14 | TomW | too many possibilities T |
| 08:03:19 | jacques | :-D |
| 08:03:28 | TomW | too many possibilities Tim and no answers yet. |
| 08:05:04 | jacques | but a heck of a lot more answers than yesterday and the day before |
| 08:05:11 | TomW | First we need to get the blob to see the full 64 meg. I am NOT convinced that this is a hardware problem, I still see no reason why the 64 meg SODIMM is not reporting in properly. I strongly suspect that the blob is at fault. How much RAM is on the LART? |
| 08:06:09 | TomW | :-) right, that is because Tim has had a lot of experience in brow-beating lowly engineers... |
| 08:07:31 | TomW | Management Rule #1: if you don't get a convincing plain-english answer then the engineer hasn't looked into the problem thoroughly enough. |
| 08:08:39 | TomW | BZFlag: crap! I never thought that I would be suffering burnout from an IRC channel. ;-) |
| 08:08:54 | BZFlag | ok, in 11x11 mode we have address pins (from table 10-6 of the sa1100 manual)... |
| 08:09:18 | BZFlag | 2-9,21-23 are rows. |
| 08:09:37 | BZFlag | 10-20 are columns. |
| 08:10:44 | scanline | is away: standing in the wet room |
| 08:10:47 | BZFlag | now a10-a20 map to sodimm a0-a10 but.. |
| 08:11:08 | BZFlag | a21 (a row address) maps to a11 on the sodimm. |
| 08:12:29 | TomW | Hmmm, that was what was lurking.. look at the end of Section 10.2.4 |
| 08:12:39 | BZFlag | in 12bit, a21 is a column address though. |
| 08:13:22 | BZFlag | huh? bclk timings? |
| 08:13:22 | TomW | umm, tired, it is Table 10-5, the answer is there. |
| 08:14:13 | TomW | Read the paragraph below that table, it starts out "Table 10-6 show the DRAM ..." |
| 08:14:20 | BZFlag | 10-5 shows a max of 64M but does not really say those are all the valid configs. |
| 08:14:26 | BZFlag | do you think they are? |
| 08:14:29 | TomW | Read the paragraph below that table, it starts out "Table 10-6 show the DRAM ..." |
| 08:15:29 | BZFlag | right, 10-6 is the table I've been reading from. |
| 08:16:42 | TomW | According to the statement in that paragraph "(12 row x 11 columns are not supported)" your 64 meg SODIMM won't work. |
| 08:16:57 | TomW | Your SODIMM is 12x11. |
| 08:17:05 | | 121 |
| 08:17:05 | BZFlag | ibot 11 * 11 |
| 08:17:05 | | 121 |
| 08:17:05 | BZFlag | ibot: 11 * 11 |
| 08:17:29 | | 22 |
| 08:17:29 | TomW | ibot: 11 + 11 |
| 08:17:32 | BZFlag | yes, but the 12 is dropped to 11 by the bank select, no? |
| 08:17:40 | TomW | now raise 2 to the 22nd power. |
| 08:17:47 | | 4194304 |
| 08:17:47 | BZFlag | ibot 2 ** 22 |
| 08:18:10 | | 16777216 |
| 08:18:10 | BZFlag | ibot 2 ** 22 * 4 |
| 08:18:29 | TomW | times two RAS lines. |
| 08:18:36 | BZFlag | hmm... so 2 16M banks is all there is. |
| 08:19:03 | TomW | yes: 2 ** 22 * four CAS lines * two RAS lines == 32Meg. |
| 08:19:48 | | 67108864 |
| 08:19:48 | TomW | ibot: 2 ** 23 * 4 * 2 |
| 08:20:12 | TomW | but 12x11 is not supported... |
| 08:21:40 | TomW | I am confused by the manual, it states that the RAM banks are 128Meg in size, yet the memory controller only allows us a 12x10, 11x11 addressing on the DRAM. The manaul doesn't explain that, the manual sucks. |
| 08:21:49 | BZFlag | could reroute nCS0 there and turn off the on board? still 64M but perhaps less work. |
| 08:24:25 | TomW | I suspec that the way that the internal logic of the SA1100 works, it breaks EVERYTHING up in to chip / peripherial selects on 128M boundries. But this isn't the limitation on how much DRAM we could have, the DRAM controller is at fault here, it is the limitation. |
| 08:24:53 | andersee | TomW: are you putting 128MB in the Tux? |
| 08:25:16 | TomW | cannot do that on the SA1100, maybe you can do that on the SA1110. |
| 08:29:17 | TomW | Yes, the SA1100 only has a DRAM controller capable of 16Meg banks, the SA1110 DRAM controller will handle up to 128Meg banks. |
| 08:29:22 | BZFlag | andersee: looks like 64M is as far as we can go. |
| 08:29:52 | TomW | 64 on the Tux. |
| 08:30:10 | TomW | andersee: what processor is in your netgear? The SA1110? |
| 08:30:14 | BZFlag | 110 |
| 08:30:26 | BZFlag | sa110 on the netwinder |
| 08:31:19 | scanline | is back (gone 00:20:34) |
| 08:32:45 | TomW | Same core as the SA1110 but with an less chip selects, no SDRAM support, etc. but same DRAM controller as the SA1110. |
| 08:33:29 | andersee | BZFlag: I have 256 MB on my netwinder... :) |
| 08:33:39 | BZFlag | whacks andersee |
| 08:34:02 | andersee | howls in pain |
| 08:35:33 | TomW | Right. you installed either two 128M modules and ran two RAS lines to it or a single 256 module and ran 4 RAS lines to it. |
| 08:36:55 | TomW | keeps falling asleep. |
| 08:37:15 | TomW | I AM out of here, good night. |
| 08:37:19 | TomW | is away: I'm busy |
| 08:38:14 | andersee | TomW: Yup. |
| 08:41:55 | BZFlag | argh... acroread killed X |
| 08:44:31 | jacques | ugh |
| 08:45:00 | jacques | i was gonna say i hate it wen that happens but that has never happened to me |
| 08:46:05 | jacques | andersee: you about? |
| 08:46:38 | jacques | andersee: does uclibc have iswalnum() ? |
| 08:46:52 | jacques | also, how goes the release? |
| 08:47:57 | BZFlag | TomW: so think about a simple hack to route nCS0 to an address line on the sodimm. that would be easier than upgrading the onboard memory for most folks. |
| 08:48:10 | andersee | I'm here |
| 08:48:14 | BZFlag | your onboard hack reroutes nCS0 anyway no? |
| 08:48:52 | jacques | BZFlag: TomW left |
| 08:49:34 | andersee | jacques: nope. The wide char ctype stuff like iswalnum() is in progress, but not in CVS yet |
| 08:52:29 | jacques | andersee: ok thanks |
| 08:52:41 | jacques | i just need to figure out how to tell gtk+ configure that |
| 08:53:12 | andersee | jacques: Manuel has worked out a way we can do full locale support for just a bit over 6k, assuming either ascii or utf8 encodings. |
| 08:53:32 | andersee | jacques: Sure beats the 170+k per locale in glibc... |
| 08:54:26 | jacques | Whoo!! |
| 08:54:47 | jacques | one of my biggest gripes is the 16MB of locale info glibc likes to install by default |
| 08:56:04 | andersee | Actually, in addition to the 6k, you would also need about 2-3k per locale. |
| 08:56:40 | andersee | err. 2-3k per _language_ really |
| 08:57:10 | BZFlag | andersee: sweet! ascii and utf8 should be fine. |
| 08:57:45 | BZFlag | I'd be fine with just utf8. ;-) |
| 08:59:23 | andersee | BZFlag: ignoring all the legacy encodings drops a _huge_ amount of crap out of the picture. And the glibc locale data has not the slightest effort at redundancy elimination. We are doing using two indirects to eliminate redundant data so we get a massive size reduction. |
| 09:03:38 | jacques | i really really wanna know how those ppl on th list compiles gtk+ against uclibc |
| 09:05:55 | BZFlag | andersee: excellent. |
| 09:58:55 | fontenot | home |
| 09:59:51 | Tangent | fontenot: Hi |
| 10:10:35 | fontenot | hi Tangent :-) |
| 10:14:47 | BZFlag | Tangent: you saw the ibot log changes I did? |
| 10:15:17 | BZFlag | the specs on the sa1100 say it can do 4 banks of 64M == 256M |
| 10:15:22 | BZFlag | don't know how though. |
| 10:18:28 | Tangent | BZFlag: Nope... what changes were those? |
| 10:18:49 | Tangent | BZFlag: I've seen a place that does 256M memory upgrades for the iPAQ |
| 10:20:16 | BZFlag | yeah, that's a sa1110 though. |
| 10:20:26 | Tangent | Good point |
| 10:20:29 | BZFlag | I split ibot's logs by channel. |
| 10:20:40 | Tangent | Ooh... excellent :) |
| 10:20:50 | Tangent | BZFlag: Thanks :) |
| 10:20:59 | | http://ipaq.secret.org.uk/~timr |
| 10:20:59 | Tangent | ibot logs |
| 10:21:07 | BZFlag | http://ipaq.secret.org.uk/~timr/tuxscreen/?N=D |
| 10:23:39 | Tangent | Yeah.. found that... |
| 10:23:52 | Tangent | was just about to post a mail to the psilinux people to let them know too... |
| 10:24:00 | Tangent | BZFlag: Fantastic :) |
| 10:24:28 | BZFlag | I got sick of digging for log history, so I hacked up the script. ;-) |
| 10:25:06 | Tangent | I hadn't been using the logs very much... it was very confusing trying to keep track of the converstaions... |
| 10:25:12 | Tangent | this should make things much much better |
| 10:26:10 | BZFlag | heh |
| 10:26:34 | Tangent | plus... how it's really easy to spot the busy days and the quiet days |
| 10:26:38 | BZFlag | well, must sleep. wish I knew why my 64M sodimm was not working... |
| 10:26:48 | BZFlag | yepper. ewll night. |
| 11:27:29 | fontenot | andersee: you about? |
| 11:27:51 | fontenot | andersee: does uclibc have getresuid and getresgid ? |
| 11:33:37 | fontenot | hmm I found the switch to turn them off in gtk, maybe I dont need them |
| 11:43:19 | fontenot | now it's complaining about mbstowcs |
| 12:07:24 | fontenot | hmm got it to build i wonder if it works |
| 12:13:20 | andersee | heh |
| 12:13:20 | andersee | checked in a makefile for links |
| 12:19:27 | fontenot | links ? |
| 12:19:57 | fontenot | ok i have notes on how to build gtk. dunno yet if it actually works |
| 12:25:48 | Souslik | Hello guys, I ordered 4 tuxscreens to ship to Belgium at the end of february, I didn't get anything at the moment. Is there a tracking number or something like that? How long should it take? |
| 12:27:05 | fontenot | Souslik: you should email Tim. his name here is BZFlag but he is not here now |
| 12:27:54 | Souslik | oki, thx for your help |
| 12:40:53 | andersee | fontenot: links is a text based web browser |
| 12:50:04 | Souslik | andersee: lynx |
| 12:53:57 | andersee | Souslik: lynx sucks. links is similar but better |
| 13:04:26 | Souslik | I'll have a llok |
| 13:04:28 | Souslik | look |
| 14:17:05 | fontenot | heh something tells me I'm not going to fit gtk in onboard flash |
| 14:30:09 | sjhill | listens carefully and hears gtk saying *oink* *oink* |
| 14:38:54 | scanline | hehe |
| 14:39:38 | scanline | was wondering why his Zaurus usually sounded like that... |
| 14:40:41 | scanline | notes the the Zaurus ROM he installed earlier allocates 26 -bleep-ing megabytes for working RAM, leaving only a 6MB ramdisk |
| 15:00:26 | TomW | GPSFan: morning. |
| 15:06:25 | TomW | is back (gone 06:29:06) |
| 15:08:05 | CosmicPenguin | is back (gone 15:06:53) |
| 15:36:04 | GPSFan | TomW: morning, hows'it? |
| 15:40:39 | prpplague | morning all |
| 15:54:24 | andersee | morning |
| 15:56:33 | sjhill | howdy |
| 16:25:44 | TomW | GPSFan: fine, little groggy from not enough sleep.. |
| 16:26:05 | TomW | GPSFan: I had my speaker turned off so I am late in replying. |
| 16:45:15 | TomW | GPSFan: do you have an unmodified Tux that you could put one of those new SODIMMs into? |
| 16:46:09 | scanline | is away: class |
| 17:24:47 | Russ--- | hey andersee |
| 17:54:18 | GPSFan | TomW: I was outside working on this nice spring day, Yes I do have a Virgin TuxScreen, and I did put one of my 32M SODIMMS in and with only a piece of tape on pin 71 it comes up as a 16M module, but that gives you 24M (8 + 16) which Linux likes just fine. |
| 17:55:55 | TomW | GPSFan: does it boot? |
| 17:56:07 | GPSFan | indeed it does. |
| 17:56:41 | TomW | GPSFan: didn't you have a problem last night that the first unit would not boot and you rewired the cpu? |
| 17:57:50 | prpplague | TomW: whats the latest on your tux-dev board? |
| 17:58:00 | GPSFan | TomW: not really, I theroized about swapping the RAS lines, and BZflag thought that if I did that that blob might not work without the larger SODIMM in place. |
| 17:58:50 | TomW | GPSFan: ok, but you only get 16meg out of the 0x1f blob for the 32Meg SODIMM? |
| 17:59:05 | GPSFan | correct |
| 17:59:38 | GPSFan | TomW: and changing to 2f makes 8 1M & 2 16M chunks. |
| 17:59:43 | TomW | GPSFan: I think that when you went to 0x2f, the system showed 8 one meg regions and two 16 meg regions, but it wouldn't boot? |
| 17:59:58 | TomW | it wouldn't boot though? |
| 18:00:30 | GPSFan | TomW: blob came up ok, but linux didn't boot till I swapped the RASs |
| 18:02:13 | TomW | GOOD! Don't modify that virgin tux, there is a problem in how blob tests its RAM. |
| 18:02:33 | GPSFan | really! please elaborate.. |
| 18:03:29 | TomW | Blob only checks every 1 meg to see that a RAM is there, it doesn't check to see if that 1 meg region is actually one meg of ram, that is what I couldn't figure out. According to my calculations, you would not have had 8 one meg regions, only 8 512K regions. |
| 18:05:27 | GPSFan | TomW: so when I swapped the RASs, Linux booted fine into the 16M region, but the 1M regions were really only 512k, and if anything went to load into them it would crash. |
| 18:07:24 | scanline | is back (gone 01:21:15) |
| 18:08:36 | scanline | is away: lunch-ish thingy... |
| 18:34:02 | scanline | is back (gone 00:25:27) |
| 18:34:59 | andersee | Hey Russ |
| 18:35:25 | TomW | GPSFan: the plan is to rewrite the blob RAM test to test & report in Kilobytes, not Megabytes. |
| 18:41:25 | andersee | Hey Russ |
| 18:41:32 | andersee | welcome back |
| 18:42:52 | GPSFan | TomW: sounds like a plan, will that result in more regions? |
| 18:46:04 | Russ | geez, talk about a consistent ping for half way around the world |
| 18:46:09 | Russ | 43 packets transmitted, 43 received, 0% loss, time 42411ms |
| 18:46:09 | Russ | rtt min/avg/max/mdev = 160.169/160.612/161.764/0.529 ms |
| 18:47:22 | TomW | GPSFan: No, but it will certainly give a hardware developer more accurate information as to what the RAM actually looks like and save hours of pain. |
| 18:49:38 | Russ | f00king connection |
| 18:50:18 | scanline | is away: circuits lab |
| 19:34:36 | LoneTech | seen bzflag |
| 19:34:42 | LoneTech | seen bzflag? |
| 19:34:52 | | BZFlag was last seen on #tuxscreen 9 hours, 8 minutes and 4 seconds ago, saying: yepper. ewll night. [Thu Apr 4 11:26:48 2002] |
| 19:34:52 | CosmicPenguin | ibot: seen BZFlag? |
| 19:35:05 | LoneTech | thanks |
| 19:35:16 | CosmicPenguin | ibot is a bit of a stickler |
| 19:42:53 | | Supreme Commander..... Bow subjects! |
| 19:42:53 | TomW | ibot: what are you? |
| 19:43:03 | | sjhill: sorry... |
| 19:43:03 | sjhill | ibot: bite me |
| 19:43:07 | | ...but ibot is <reply> Supreme Commander..... Bow subjects!... |
| 19:43:07 | TomW | ibot: you are just a dumb slave. |
| 19:43:31 | | TomW: excuse me? |
| 19:43:31 | TomW | ibot: bite sjhill |
| 19:43:38 | sjhill | heh |
| 19:44:26 | TomW | You notice that when the channel goes quiet that there is always someone willing to stir things up by messing with ibot? |
| 19:45:18 | sjhill | TomW: yup :) |
| 19:45:39 | | TomW: I forgot ibot |
| 19:45:39 | TomW | ibot: forget ibot |
| 19:45:42 | | andersee: sorry... |
| 19:45:42 | andersee | ibot: kiss my rusty butt |
| 19:45:58 | | andersee is nothing but a culturally-unsound heap of halfbaked waffle-house grits. |
| 19:45:58 | sjhill | ibot: insult andersee |
| 19:46:00 | | OK, TomW. |
| 19:46:00 | TomW | ibot: you are a lowly slave. |
| 19:46:02 | sjhill | excellent |
| 19:46:05 | Russ | andersee: the libptheads implementation doesn't have semaphores |
| 19:46:07 | | i heard i was a lowly slave. |
| 19:46:07 | TomW | ibot: what are you? |
| 19:46:30 | TomW | heh, gotta keep 'me in its' place. |
| 19:46:33 | | ...but ibot is a lowly slave.... |
| 19:46:33 | andersee | ibot: You are a sleezy slimy grime sucking heap of fermented dromedary camel spit |
| 19:46:41 | sjhill | Russ: oh yeah? well back in my day we did threads without locking :) |
| 19:47:03 | Russ | andersee: sem_post, sem_wait, etc |
| 19:47:16 | Russ | andersee: also, pthead_exit is missing |
| 19:47:22 | Russ | thread, not thead |
| 19:47:44 | Russ | and sem_init |
| 19:48:51 | Russ | brb |
| 19:49:01 | andersee | Russ: Hmm. uClibc/libpthread/linuxthreads/semaphore.c seems to have sem_post and such |
| 19:49:05 | andersee | Russ: I see |
| 19:49:26 | Russ | hmm |
| 19:49:33 | Russ | somehow that CVS update didn't go through |
| 19:49:36 | andersee | Russ: Looks like it has some idiot symbol versioning crap inherited from glibc |
| 19:49:48 | Russ | hold on |
| 19:50:05 | andersee | makes a mental note to axe symbol verioning in libpthread |
| 19:50:36 | Russ | hmm...didn't help |
| 19:51:01 | Russ | huh+ |
| 19:51:07 | Russ | now I'm really confused |
| 19:51:13 | Russ | timmy:~/src/nesa/sources/uClibc/libpthread$ cvs update -dP |
| 19:51:18 | Russ | cvs server: Updating . |
| 19:51:18 | Russ | cvs server: Updating linuxthreads |
| 19:51:19 | Russ | etc |
| 19:51:23 | Russ | but no linuxthreads dir |
| 19:51:57 | LoneTech | I have sem_* stuff in mine |
| 19:52:03 | Russ | the linuxthreads dir is removed from CVS |
| 19:52:03 | andersee | Perhaps your version of CVS needs an update? Grab a daily snapshot. |
| 19:52:13 | Russ | ? |
| 19:52:23 | Russ | Concurrent Versions System (CVS) 1.11.1p1 (client/server) |
| 19:52:24 | andersee | The daily snapshots have anon cvs setup |
| 19:52:28 | LoneTech | and pthread_exit |
| 19:52:44 | andersee | $ dpkg -l cvs | tail -n 1 |
| 19:52:44 | andersee | ii cvs 1.11.1p1debian Concurrent Versions System |
| 19:52:46 | Russ | :pserver:anonymous@busybox.net:/var/cvs |
| 19:52:57 | Russ | uClibc/libpthread |
| 19:53:05 | andersee | That should work then. |
| 19:53:10 | andersee | Whats in your .cvsrc file? |
| 19:53:15 | Russ | D2002.01.02.21.40.35 |
| 19:53:17 | Russ | ah |
| 19:53:29 | Russ | blank |
| 19:53:44 | andersee | 'cvs up -A' needed perhaps? |
| 19:53:55 | Russ | cvs update -r HEAD -dP |
| 19:53:59 | andersee | Perhaps you pegged things to some date |
| 19:54:10 | Russ | ya, that was the D2002.01.02.21.40.35 |
| 19:54:23 | Russ | (from CVS/Tag |
| 19:54:42 | andersee | 'cvs up -A' will wipe all such from the whole tree |
| 19:55:20 | Russ | cvs server: cannot open directory /var/cvs/uClibc/ldso/d-link: No such file or directory |
| 19:55:25 | Russ | cvs server: cannot open directory /var/cvs/uClibc/libc/sysdeps/linux/mipsel: No such file or directory |
| 19:55:51 | andersee | rm -rf ldso /sysdeps/linux/mips* |
| 19:55:58 | sjhill | eek! |
| 19:56:03 | andersee | Then `cvs up -A` again |
| 19:56:14 | sjhill | ah |
| 19:56:22 | LoneTech | perhaps -d too? |
| 19:56:29 | andersee | At one point in the past, andersee did something evil to libc/sysdeps/linux/mipsel |
| 19:56:32 | Russ | -dP is best |
| 19:59:31 | andersee | Russ: Actually, you may need to manually remove mipsel from libc/sysdeps/linux/CVS/Entries... |
| 20:04:13 | Russ | hmmm |
| 20:04:21 | Russ | /usr/arm-linux-uclibc/lib/libc.so: undefined reference to `_strto_l' |
| 20:05:04 | Russ | ah |
| 20:05:34 | Russ | er... |
| 20:09:52 | andersee | Done a make clean? |
| 20:10:10 | andersee | After such an update, a make clean is certainly in order.... |
| 20:11:07 | Russ | ya, that fixed it |
| 20:11:49 | TomW | prpplague: Didn't mean to ignore you this morning, just stuff was happening all at once. |
| 20:16:44 | prpplague | TomW: np, i'm pretty swamped too |
| 20:17:15 | TomW | prpplague: nice to be busy though. |
| 20:18:05 | scanline | is back (gone 01:27:48) |
| 20:20:22 | prpplague | TomW: yep |
| 20:30:05 | andersee | heh |
| 20:30:14 | andersee | Tuxscreen.net just got slashdotted |
| 20:30:28 | TomW | ?? |
| 20:30:48 | andersee | Linked from "Seeking Arguments Against the CBDTPA?" |
| 20:31:55 | scanline | congrats |
| 20:32:09 | TomW | Uh oh, better get those extra tux'es before the get sold out.. |
| 20:32:19 | TomW | s/the/they/ |
| 20:44:47 | | TomW: I forgot ibot |
| 20:44:47 | TomW | ibot: forget ibot |
| 20:45:21 | | i haven't a clue, tomw |
| 20:45:21 | TomW | ibot: what are you <reply> a state machine. |
| 20:46:31 | | i think i am a moron |
| 20:46:31 | andersee | ibot: ibot? |
| 20:47:14 | | i am probably a moron |
| 20:47:14 | TomW | ibot: what are you |
| 20:47:42 | | TomW, I didn't have anything matching 'ibot.' |
| 20:47:42 | TomW | ibot: forget ibot. |
| 20:47:47 | | TomW: I forgot ibot |
| 20:47:47 | TomW | ibot: forget ibot |
| 20:48:41 | | OK, TomW. |
| 20:48:41 | TomW | ibot: You are a Micro$oft minion lurking on this channel in the hopes of obtaining innovative technology to add to the next Windoz release. |
| 20:48:46 | | i am a Micro$oft minion lurking on this channel in the hopes of obtaining innovative technology to add to the next Windoz release. |
| 20:48:46 | TomW | ibot: ibot? |
| 20:48:54 | | i am probably a Micro$oft minion lurking on this channel in the hopes of obtaining innovative technology to add to the next Windoz release. |
| 20:48:54 | TomW | ibot: who are you |
| 20:49:02 | | somebody said i was a Micro$oft minion lurking on this channel in the hopes of obtaining innovative technology to add to the next Windoz release. |
| 20:49:02 | TomW | ibot: what are you |
| 20:49:19 | TomW | heh |
| 21:08:50 | CosmicPenguin | Who is ccfpark? Anyone we know? |
| 21:16:14 | andersee | Not anyone I recognize |
| 21:18:10 | sjhill | andersee: you know, i like risc and all, but the MIPS relocation and GOT stuff is messy |
| 21:19:00 | andersee | I believe you! |
| 21:19:21 | andersee | Getting shared libs on arm to work was painful... |
| 21:20:26 | andersee | is away: taking the kids to the library |
| 21:51:54 | TomW | is away: I'm busy |
| 22:00:16 | Russ | notices the shameless tuxscreen plug on /. |
| 22:07:46 | BZFlag | heh, gotta love it. ;-) |
| 22:46:01 | BZFlag | jdb sent me some info on working around the 4+16M memory limitations. |
| 22:46:47 | BZFlag | IMHO MDCNFG:DRAC is a bit of a misnomer. A0-25 are always all driven |
| 22:46:47 | BZFlag | during the RAS phase (in my rev of the SA-1100 Tech Dev Man there is |
| 22:46:47 | BZFlag | a note below table 10.6 that says so); DRAC just determines which |
| 22:46:47 | BZFlag | address lines are driven in the CAS phase. I tend to always set DRAC |
| 22:46:47 | BZFlag | to 11 bits; as long as you are careful not to use the same address |
| 22:46:48 | BZFlag | bit for RAS and CAS phases (ie don't connect A21-23 to the DRAM) the |
| 22:46:50 | BZFlag | worst that'll happen are memory holes (like on the LART). |
| 22:50:33 | BZFlag | so a 16x8 layout per bank is possible, yes? |
| 23:03:28 | | sjm: i'm not following you... |
| 23:03:28 | sjm | ibot: ccfpark |
| 23:24:29 | | OK, BZFlag. |
| 23:24:29 | BZFlag | ibot ccfpark is probably "Cliff Campbell" <CCampbell56@home.com> now at ccfpark2@attbi.com |
| 23:25:07 | | 16777216 |
| 23:25:07 | BZFlag | ibot 2 ** (16 + 8) |
| 23:33:26 | sjm | andersee: that m68k/uClibc-0.9.10 problem I sent to the uClinux-dev list doesn't exist with the latest cvs. Thanks. |
| 23:34:33 | scanline | BZFlag: think you'll have any Tuxes left after this slashdotting? |
| 23:44:09 | BZFlag | don't know. the orders have not started pouring in yet. ;-) |
| 23:56:43 | CosmicPenguin | You sold a copule hundred from the last slashdotting, didn't you? |
| 23:58:29 | BZFlag | yep. and about 330 left at the moment. |