**** BEGIN LOGGING AT Tue Feb 15 23:59:56 2005 Feb 16 09:20:10 * prpplague gathers some eye of newt, chickens foot, and tannus root inorder to conjure the apperance of beewoolie Feb 16 09:32:34 anyone doing apex code work? Feb 16 09:33:02 <[g2]> prpplague, I've looked at the code and run it from RAM Feb 16 09:33:37 [g2]: i want to make sure i understand whats going on here Feb 16 09:34:09 [g2]: the code is getting started on the reset vector, the code is then copied to ram, and then jumps to that location Feb 16 09:34:43 [g2]: questions is, is the location that it jumps to, the start of the loader again? or is it offset to start at a specific location in the loader? Feb 16 09:40:19 <[g2]> prpplague, last I check it setup RAM first and the c stack, I didn't get to the relocation point, I believe the mmu is setup also Feb 16 09:41:27 <[g2]> my totally limited understanding is that it'll setup RAM, and the mmu and relocate itself in accordance with the ARM arch layout and then begin execution Feb 16 09:41:44 <[g2]> The code is teeny tiny and well organized Feb 16 09:42:03 <[g2]> which specific code are you talking about Feb 16 09:42:16 [g2]: from the entry.c it does, platform specific setup, then calls a relocation funtion, before it does the stack setup Feb 16 09:42:48 arch-arm/entry/entry.c Feb 16 09:42:58 and arch-arm/lib/relocate.c Feb 16 09:44:24 <[g2]> The relocator Feb 16 09:44:24 <[g2]> will put the loader at the VMA and then return to the relocated address. Feb 16 09:44:59 [g2]: yea thats what the top comment says Feb 16 09:45:10 [g2]: the bottom comment says "return to sdram" Feb 16 09:45:18 <[g2]> __asm volatile ("add pc, %0, %1" : : "r" (offset), "r" (lr)); Feb 16 09:46:11 [g2]: isnt that saying to add to the program counter the address where the program is stored in ram? Feb 16 09:51:37 <[g2]> prpplague, my guess at what's happening is that the lr holds the offset to the calling programs return instruction Feb 16 09:52:31 <[g2]> since the offset from the base starting address is the same then you wind up at the returning instruction in ram Feb 16 09:53:10 <[g2]> I can see OFFSET being that address Feb 16 09:53:51 [g2]: lr is showing up as the same as the address where the code is suppose to be loaded into ram Feb 16 09:55:10 * prpplague reruns tests Feb 16 09:56:31 yea, the lr is equal to the apex_vma Feb 16 09:56:46 and offset appears to be 0x00 Feb 16 09:57:16 <[g2]> so apex_vma + lr == SDRAM addr Feb 16 09:57:34 <[g2]> of the returning instruction Feb 16 09:57:59 apex_vma=lr Feb 16 10:03:48 <[g2]> prpplague, well that + 0 works too :) Feb 16 10:04:33 [g2]: yea, guess the offset is the problem then Feb 16 10:05:11 [g2]: becuase if you copy apex to ram at location 0x20200000 and your offset is 0x00 , then you are starting at the begging of apex again Feb 16 10:05:44 (as i understand it) Feb 16 10:06:08 <[g2]> well if apex_vma = flash addr that would happen Feb 16 10:06:16 <[g2]> lunch Feb 16 10:06:33 [g2]: ? will happen too if its ram and the ram is a copy of the flash Feb 16 10:07:50 <[g2]> ram is supposed to be a copy of the flash (that's the whole point of the relocation) Feb 16 10:08:27 <[g2]> but at virtual address instead of a physical addr Feb 16 10:11:24 [g2]: right Feb 16 10:12:19 [g2]: offset should the offset of the where the current program address is Feb 16 10:12:47 [g2]: if a duplicate of the flash is in ram at that address and i'm jumping to that address, i'm starting apex over Feb 16 10:25:04 <[g2]> prpplague, I don't know arm assembler very well, but the jumps are relative to some number of address bits Feb 16 10:25:52 <[g2]> and longjump is used for addressees that exceed the local jumping ability in the Instruction Set Architecture (ISA) Feb 16 10:26:23 <[g2]> 16K is < 15 bits Feb 16 10:26:29 [g2]: right Feb 16 10:26:55 <[g2]> so we are really talking about a page offset + 15-16 bits relative offset Feb 16 10:27:15 [g2]: right, but if the offset is 0 Feb 16 10:27:21 <[g2]> I'm sure the apex map file lays it all out Feb 16 10:27:23 [g2]: we just end up at the same address Feb 16 10:27:36 [g2]: yea, from what i can tell its the offset thats wrong Feb 16 10:29:01 [g2]: the offset _should_ be a value representing where it should jump to starting at the lr address (where lr is the apex_vma address) Feb 16 10:35:11 <[g2]> "moveq pc, %1\n\t" /* Return when already reloc'd */ Feb 16 10:35:54 <[g2]> it's that just a check if it's calling itself a second time ? Feb 16 10:36:50 [g2]: yea Feb 16 10:37:23 [g2]: if the current program counter is equal to the lr(apex_vma) then its already in ram Feb 16 11:18:10 heya kas11 Feb 16 11:18:45 ;) @ ka6sox Feb 16 11:38:08 key kids Feb 16 11:39:33 <[g2]> morning sunshine ! Feb 16 12:32:14 beewoolie: d00d Feb 16 12:32:19 beewoolie: whats cookin? Feb 16 12:32:44 prpplague: Good news is that I've successfully built one of the packages I need for my demo. Feb 16 12:32:51 Even scratch box didn't work. Feb 16 12:32:58 beewoolie: cool Feb 16 12:33:04 s/scratch box/scratchbox/ Feb 16 12:33:29 And I'm still looking for people who recognize how bad automake is. :-) Feb 16 12:34:09 hehe Feb 16 12:34:11 i do Feb 16 12:34:21 Yippee! I've got one friend. Feb 16 12:34:25 beewoolie: still having problems with apex though Feb 16 12:34:31 prpplague: shoot Feb 16 12:34:50 Did you get the debug_ll working? Feb 16 12:35:26 beewoolie: the debug_ll stuff shows what i already knew, that the relocate function runs but at the point where we are suppose to return to ram, the program dies Feb 16 12:35:52 Set a breakpoint and look at memory. Feb 16 12:36:54 beewoolie: my question is, what is the offset and lr values suppose to be on the lpd79520 board? Feb 16 12:37:32 lr is the return address from where the loader first was running, back to the entry function. Feb 16 12:37:42 It should be something low, like x230 Feb 16 12:38:28 Offset should be something that moves you to SDRAM, 0x00200000 Feb 16 12:38:47 What are you getting? Feb 16 12:39:12 i'm getting 0x2020000 for lr and 0x00 for offset Feb 16 12:42:57 That shouldn Feb 16 12:42:59 t be Feb 16 12:43:15 That means you are already running is SDRAM. Feb 16 12:43:36 If you break at the top of the relocate function and look at the registers, what is PC? Feb 16 12:45:30 one sec Feb 16 12:55:16 beewoolie: pc = 0x025C Feb 16 12:55:50 Hmm. Let me check the source again. That is correct. Feb 16 12:58:18 prpplague: I am beginning to suspect that this is a compiler problem. Can you do this: Feb 16 12:58:34 # make src/arch-arm/lib/relocate.s Feb 16 12:58:38 and send me the .s file? Feb 16 12:58:49 yea Feb 16 12:58:55 one sec Feb 16 13:01:24 otw Feb 16 13:04:45 beewoolie: got it? Feb 16 13:05:12 Just reading email... Feb 16 13:05:54 ok Feb 16 13:06:42 yep. It's a compiler problem. Feb 16 13:06:51 ahhhhh Feb 16 13:06:56 beewoolie: whats it doing? Feb 16 13:07:00 it is putting the return address into r1 and then stomping all over it. Feb 16 13:07:12 ahh Feb 16 13:07:16 Guess I'll have to make a note of that in the release notes. Feb 16 13:07:41 Funny thing, though, is that it does run for me. It might be better if you remove the debug_ll calls. Feb 16 13:08:04 I have been suspicious of the compiler being correct about register assignments Feb 16 13:08:17 There have been some notes about it on the arm list. Feb 16 13:08:29 beewoolie: ok, i'll remove the calls inside the relocate.c and test Feb 16 13:08:40 What sux is that the compiler isn't using LR, so the correct lr value is available. Feb 16 13:08:52 It just doesn't know it. Feb 16 13:09:29 yea, i was wondering about that Feb 16 13:12:34 looks like its still stomping it Feb 16 13:13:19 Send me the .s file. Feb 16 13:13:47 beewoolie: this is just with the debug_ll's removed Feb 16 13:13:59 Right. Feb 16 13:14:05 one sec Feb 16 13:15:18 otw Feb 16 13:17:03 prpplague: I have a 2.95.3 compiler that works. Feb 16 13:17:15 beewoolie: oh? Feb 16 13:17:26 Where did you get your compiler? Feb 16 13:17:46 beewoolie: i have two that i use, one is from the lart pages the other built from scratch Feb 16 13:18:00 How do you build from scratch? Feb 16 13:18:35 The code you sent looks correct. Feb 16 13:18:41 beewoolie: we have a buildscript based on an sdk from lineo Feb 16 13:18:52 beewoolie: the code looks ok? hmm Feb 16 13:18:53 How do you know it is stomping on the registers. Feb 16 13:18:57 ? Feb 16 13:19:16 Um, considering how bad the lineo work was, I'd say you need to look to crosstool to build a cross cmpiler. Feb 16 13:19:17 beewoolie: since the behavior was the same Feb 16 13:19:26 Not a good assumption. :-) Feb 16 13:19:36 beewoolie: i said based on, not the actually item Feb 16 13:19:51 Still, I'd recommend that you use cross-tool. Feb 16 13:19:59 beewoolie: this also was used by pb_ and several other ppl so i'm confident its pretty solid Feb 16 13:20:15 Well, we have evidence otherwise. Feb 16 13:20:35 Note that there are lots of programs that 2.95 builds, but that doesn't mean it is always correct. Feb 16 13:20:49 beewoolie: this is the first time i've had any problems, but i'll try it with a different toolchain Feb 16 13:21:26 prpplague, what was the 2232 based dual serial that you found? Feb 16 13:21:57 prpplague: The code you sent and my code are identical. Feb 16 13:23:08 beewoolie: hmm Feb 16 13:23:54 beewoolie: well with that code, i get A at the end which indicates to me that is returning to the begging of apex Feb 16 13:24:28 ka6sox: you want the dlpdesign module or an off the shelf dual serial device for hacking? Feb 16 13:24:37 the later Feb 16 13:24:58 prpplague: With a debugger, this ought to be really easy. Stop at the end of relocate and look at memory. Feb 16 13:25:13 prpplague: You can tell exactly what it is going to do. Feb 16 13:25:35 * prpplague is up to speed on using the lauterbach software for debugging Feb 16 13:25:40 s/is/isn't Feb 16 13:25:56 prpplague: I hate to say it, but you're making this far more difficult than it has to be. Feb 16 13:26:06 beewoolie: i like difficult, hehe Feb 16 13:26:07 The loader isn't very big. Feb 16 13:26:12 beewoolie: agreed Feb 16 13:26:16 You could step the code Feb 16 13:26:48 beewoolie: like i said, just not used to the lauterbach stuff, gonna have to do a little learning on it first Feb 16 13:27:08 beewoolie: just surprised that its not working better Feb 16 13:27:35 didn't have this much trouble getting blob or our custom bootloader up and running Feb 16 13:27:41 prpplague: I'd start with the toolchain. I don't trust Lineo. I trust cross-tool. Feb 16 13:27:54 Blob doesn't use the compiler much. Feb 16 13:28:05 beewoolie: like i said the buildscripts were based on it not the actual unit Feb 16 13:28:07 dyoung: morning. Feb 16 13:28:17 beewoolie: trying a 3.3 toolchain now Feb 16 13:28:39 prpplague: Huh? beewoolie: like i said the buildscripts were based on it not the actual unit Feb 16 13:29:40 beewoolie: the design was based on the layout from lineo Feb 16 13:29:46 beewoolie: not the actual results Feb 16 13:29:57 beewoolie: no patchs or anything from lineo Feb 16 13:30:21 prpplague: I haven't looked closely at cross tool. I do know that he has applied patches to most of the compilers. Feb 16 13:34:45 prpplague: It look like the problem is that the 2.95.3 compiler doesn't recognize the naked attribute. It's attempting to store values on the stack. This is a no-no as we don't yet have a stack. Feb 16 13:34:54 prpplague: Even my version does this. Feb 16 13:35:07 beewoolie: ahh Feb 16 13:35:17 prpplague: blob doesn't have this problem because it doesn't use this feature of the compiler. Feb 16 13:35:36 prpplague: I do because it is easier than hand coding these routines. Feb 16 13:39:43 moring. Feb 16 13:40:14 prpplague: so, I am able to run a GCC 2.95.3 APEX on the lh79524. I can't test the 79520 right now, but I cannot see why it wouldn't work. Feb 16 13:41:14 beewoolie: ok Feb 16 13:41:25 beewoolie: i'll continue to search for the issue Feb 16 13:41:43 The easiest thing to do is break at the end of relocate_apex and see where it is going. Feb 16 13:42:00 beewoolie: yea, gonna have to do that Feb 16 13:42:06 Either the data wasn't copied, or it is corrupt because of a setup problem, or the jump address is wrong. Feb 16 13:42:39 beewoolie: based on the data i got out of the debug_ll stuff, i suspect that the jump address is wrong for some reason Feb 16 13:43:11 prpplague: see is believing. Feb 16 13:43:18 beewoolie: i really like the design overall Feb 16 13:43:28 beewoolie: gonna be nice to start doing my mmc dev with it Feb 16 13:44:34 beewoolie: any reason the relocate routine would not be 16-bit bus safe? since both my ram and flash are 16-bit bus Feb 16 13:45:09 Shouldn't care. Feb 16 13:45:30 yea i didn't think so, but i figured i'd ask Feb 16 13:45:43 Relocate copies words and it copies eight at a time. Kinda overkill, I know. Feb 16 13:46:09 I could probably alleviate the register crunch by moving only four words at a time. Feb 16 13:46:31 * prpplague looks at the relocate routine in his custom loader Feb 16 13:49:38 * prpplague hmmmm's Feb 16 13:54:49 beewoolie: at the end of the relocate code, we are returning to the entry code thats in ram, correct? Feb 16 13:55:08 Right. Feb 16 13:58:45 beewoolie: well, i'm about 99% certain i have all the correct values for the sdram init Feb 16 13:58:55 beewoolie: been over that with a fine tooth comb Feb 16 13:58:58 prpplague: seeing is believeing. Feb 16 13:59:15 prpplague: your reluctance to use the debugger is amusing Feb 16 13:59:37 prpplague: How many hours have we spent on this? Feb 16 13:59:53 beewoolie: not reluctance, i've spent about 5 or 6 Feb 16 14:00:06 beewoolie: but it was also learning about the layout of apex Feb 16 14:00:24 prpplague: call it what you will. This problem would be solved by a 15 minute debug session Feb 16 14:00:45 beewoolie: just different learning process Feb 16 14:06:15 beewoolie: btw, whats this section of code for in the init-lpd79520.c : Feb 16 14:06:16 __asm volatile ("tst %0, #0xf0000000\n\t" Feb 16 14:06:16 "beq 1f\n\t" Feb 16 14:06:16 "cmp %0, %1\n\t" Feb 16 14:06:16 "movls r0, #0\n\t" Feb 16 14:06:16 "movls pc, %0\n\t" Feb 16 14:06:18 "1:" :: "r" (lr), "i" (SDRAM_BANK1_PHYS)); Feb 16 14:06:55 prpplague: It prevents the SDRAM init from executing when APEX is already executing from SDRAM. Feb 16 14:07:31 The first instruction masks the top nibble. Feb 16 14:07:49 If it is zero, it will jump past the rest of the code to perform the SDRAM init. Feb 16 14:08:33 beewoolie: this would apply if you had loaded apex into ram and jump to the ram address Feb 16 14:08:46 prpplague: right. Which we do. Feb 16 14:09:18 beewoolie: ok, i must be miss understanding the process then Feb 16 14:09:19 prpplague: It will still relocate, it just won't pull the rug from beneath itself. BLOB kinda did this too, but the code was wrong. Feb 16 14:09:59 prpplague: I mean that we do load APEX into SDRAM in some cases. You are running from flash, so this code should let you to the SDRAM init. Feb 16 14:10:53 beewoolie: ok, my question is why does it refer to sdram_bank1 ? Feb 16 14:11:30 beewoolie: the lpd79520 only has one bank, iirc from the config Feb 16 14:11:51 Right. So, SDRAM is all that is less than the start of bank1. Feb 16 14:12:10 This could be bank1+sizeof(bank1), but that wasn't necessary. Feb 16 14:12:46 you mean bank0+sizeof(bank0)? Feb 16 14:12:55 You'll see that the code *does* set the mode for bank1. It's a harmless addition that makes is clear what has to happen to add another bank. Feb 16 14:13:05 beewoolie: yea i saw that Feb 16 14:13:21 prpplague: No, I mean bank1+sizeof(bank1). If there is a second bank, APEX could be running from it. Feb 16 14:13:51 ok, so the second bank is bank2? Feb 16 14:14:07 Um. no. Bank0 and Bank1. Feb 16 14:14:23 i didn't think so Feb 16 14:14:33 * prpplague is still confused, but will study the code Feb 16 14:14:38 #define SDRAM_BANK0_PHYS 0x20000000 Feb 16 14:14:38 #define SDRAM_BANK1_PHYS 0x28000000 Feb 16 14:15:15 These are defined for the processor. the code in the startup isn't quite correct. Feb 16 14:15:53 To be correct, it should test for APEX running in either bank. As it stands, it does the right things if APEX is running in BANK0, flash, or SRAM. Feb 16 14:16:04 That is the point of the code. Feb 16 14:17:27 beewoolie: ok, so once the code is relocated, are you returning the offset of where the relocation function was called, or are you starting the apex code from the begging(but running from ram)? Feb 16 14:22:27 beewoolie: shouldn't setting the IOCON_MEMMUX be done with the sdram init section after this test? Feb 16 14:23:07 prpplague: looking Feb 16 14:25:23 prpplague: It should be harmless. Feb 16 14:25:48 It doesn't turn off SDRAM. It just turns on other things. Feb 16 14:26:13 prpplague: You could make it more specific with a mask and set. Feb 16 14:26:59 beewoolie: yea, i'm just assigning a value for now Feb 16 14:29:42 beewoolie: the lineo patches as well as the code i did only copy a single word at at time Feb 16 14:30:22 prpplague: APEX is small enough, that it wouldn't matter if we only copied 1 word at a time. Feb 16 14:30:41 prpplague: There's no compelling reason to change the code at this point. Feb 16 14:36:21 beewoolie: ok, so...., with the debug's removed from relocate.c, on the uart i get AErA Feb 16 14:36:56 prpplague: and where is relocate jumping to when it leaves? Feb 16 14:37:54 prpplague: appears to be jumping to 0x20200000 Feb 16 14:38:14 beewoolie: which is the apex_vma address Feb 16 14:38:30 that would be wrong. Feb 16 14:38:47 beewoolie: what should it be? Feb 16 14:38:49 It should be jumping to that address plus a 0x260 or something like it. Feb 16 14:39:16 The return from relocate is add pc, lr, offset where lr and offset are really regisgters Feb 16 14:39:31 right thats what i figured Feb 16 14:39:43 That means that the offset value is getting lost Feb 16 14:39:57 The assembler code looked ok. You can step it to see what it does. Feb 16 14:40:48 The idea is that the bl to reloc: will put into the lr register the address of the reloc label. I subtract that from the linked address of reloc and the difference is the offset. Feb 16 14:41:28 beewoolie: right Feb 16 14:41:56 Either the math is failing or the register is getting stomped. Feb 16 14:42:10 The code looked ok last time I saw it. Feb 16 14:42:24 beewoolie: yea, thats what confused me when i saw the offset and lr's with debugs Feb 16 14:42:48 How do you know it is jumping to 0x20200000? Feb 16 14:44:51 beewoolie: had a look at lr Feb 16 14:44:59 beewoolie: on the return Feb 16 14:45:11 What were the other registers? Feb 16 14:45:49 beewoolie: didn't write them down, i can re-grab them in a few, i'm reflashing at the momment Feb 16 14:46:20 The other registers will tell us the whole story. Feb 16 14:47:29 big difference in the .s files between 2.95.3 and 3.3 Feb 16 14:47:42 For which sources? Feb 16 14:50:14 the relocate.s Feb 16 14:50:27 Hmm. Feb 16 14:50:32 Hadn't noticed. Feb 16 14:50:37 There isn't much code there. Feb 16 14:52:55 beewoolie: but the registers that are used are different Feb 16 14:53:20 prpplague: IIRC, the 3.3 compilers have much better register flow Feb 16 14:57:38 beewoolie: might not get to debugging with jtag this afternoon, was registers did you want values for? Feb 16 14:58:07 prpplague: all. There are only 16. Feb 16 14:58:59 beewoolie: right Feb 16 14:59:59 The two things that I'd look for are 1) the address relocate_apex is jumping to when it returns and where this value comes from Feb 16 15:00:09 and 2) the word value at that address. Feb 16 15:01:11 ka6sox: sorry, didn't get back with you, i don't have the url handy, i'll look for it this evening Feb 16 15:01:23 prpplague, np Feb 16 15:30:36 hi Feb 16 16:53:39 Hey folks, get a load of this: http://www.theinquirer.net/?article=21267 Feb 16 16:54:10 Could be handy for adding drives to slug-like things. Feb 16 16:56:01 I don't think it's something we'd hack, but it means we should be seeing really cheap USB2.0 drives hitting the market. Feb 16 17:04:49 <[g2]> beewoolie, I thought that was cool too Feb 16 17:05:22 <[g2]> hey Jason_ welcome Feb 16 17:05:26 There's a part of me, the part that thinks I have infinite free time, that would like to hack it. Feb 16 17:05:53 [g2]: It's been kinda quiet. Feb 16 17:19:41 :\ Feb 16 17:19:44 <[g2]> :) Feb 16 17:20:22 out where TekGecko lives there are certianly plenty of them. Feb 16 17:20:32 <[g2]> hey ka6sox ! Feb 16 17:20:47 <[g2]> any luck with the FedEx man or equivalent ? Feb 16 17:20:48 still hoping to make the mail today. Feb 16 17:20:54 headed over in a few. Feb 16 17:20:59 <[g2]> cool Feb 16 17:21:04 been struggling to get something done. Feb 16 17:21:19 <[g2]> how's the car doing ? Feb 16 17:22:08 it took 2 tow trucks to extract it. Feb 16 17:22:22 <[g2]> it's free and fine now ? Feb 16 17:22:27 free but wounded Feb 16 17:22:41 <[g2]> side panel or axel ? Feb 16 17:22:51 side and rear bumper Feb 16 17:23:15 .. pleny of what? Feb 16 17:23:22 ka6sox what happened to your car? Feb 16 17:23:39 plenty* Feb 16 17:23:43 last friday nite I crashed into a mountain. Feb 16 17:23:50 in the rain Feb 16 17:24:02 oh crap I didn't hear about that :-( Feb 16 17:24:39 and I've been out of sorts since having to walk about 5 miles to a McDonalds at 3am. Feb 16 17:24:42 The Oxford Semi thing isn't a particularly amazing step in technology. They make/made plain PATA ones anyway so they just bolted on a SATA interface instead Feb 16 17:24:56 <[g2]> ls Feb 16 17:24:59 Into a mountain?! Feb 16 17:25:03 yes. Feb 16 17:25:19 Mail redboot tmp Feb 16 17:26:12 McDonalds was open at 3am? Feb 16 17:26:48 Tiersten, I guess he was expecting the mountain to move out of the way. Feb 16 17:26:53 And oyu were that desperate for a Big Mac that you walked 5 miles? Feb 16 17:26:55 heh Feb 16 17:26:58 Hope you're okay tho Feb 16 17:28:48 Tiersten: Not spectacular, but the SATA market is blooming. And the drives seem to be cheaper than the PATA versions. Feb 16 17:29:03 Are they? Not looked in a while :) Feb 16 17:29:05 ka6sox: bummer about the car. Does it still run? Feb 16 17:29:40 Tiersten: I suspect it has something to do with integration. Fewer wires. Feb 16 17:30:07 Bigger market most probably since everything is moving over to it Feb 16 17:30:24 The original drives were crap since they were actually PATA drives with a SATA bridge chip built into it Feb 16 17:30:42 Know it. Feb 16 17:31:28 Tiersten: I've been wondering. what can you do with a BDI and a slug if you don't have the xscale firmware for the BDI? Feb 16 17:32:05 Flash Feb 16 17:32:23 Really? How. My BDI doesn't even see the slug hardware. Feb 16 17:32:39 That would be a big help if I could get that working. Feb 16 17:32:44 beewoolie, yes it does...but I had to wait for a ride to L.A. about 6hrs later Feb 16 17:32:46 Hrmm. Not sure then. It works for the one at work Feb 16 17:33:06 <[g2]> beewoolie, apex> boot console=ttyS0,115200 root=/dev/mtdblock4 rootfstype=jffs Feb 16 17:33:06 <[g2]> Booting kernel at 0x00008000... Feb 16 17:33:06 <[g2]> Uncompressing Linux........................................................... Feb 16 17:33:06 <[g2]> crc error Feb 16 17:33:21 <[g2]> apex => mem:0x00200000+0x5c30 Feb 16 17:33:21 <[g2]> env => nor:128k+64k Feb 16 17:33:21 <[g2]> Use the 'help .' command to get a list of help topics. Feb 16 17:33:21 <[g2]> # copy nor:0x60010+0xffff0 0x00008000 Feb 16 17:33:21 <[g2]> 1048560 bytes transferred Feb 16 17:33:22 <[g2]> # copy nor:0x160010+0x69fff0 0x01000000 Feb 16 17:33:28 <[g2]> 6946800 bytes transferred Feb 16 17:33:54 <[g2]> the copy nor:0x60010+0xffff0 0x00008000 Feb 16 17:33:58 [g2]: hang on a second.... Feb 16 17:34:14 <[g2]> copies the kernel from flash to memory Feb 16 17:34:41 <[g2]> 1MB-16bytes worth Feb 16 17:36:13 [g2]: Is this the stock kernel? Feb 16 17:36:22 <[g2]> no it's the openslug kernel Feb 16 17:36:31 <[g2]> the OpenSlug stock kernel Feb 16 17:36:33 [g2]: Also, can you dump the memory at the top of the kernel area. Feb 16 17:36:45 apex> du nor:0x60000 Feb 16 17:37:06 <[g2]> rebooting Feb 16 17:37:09 <[g2]> will do Feb 16 17:38:15 <[g2]> apex> du nor:0x60000 Feb 16 17:38:15 <[g2]> 00060000: 00 0d 39 30 00 00 00 00 00 00 00 00 00 00 00 00 ..90.... ........ Feb 16 17:38:15 <[g2]> 00060010: e1 a0 00 00 e1 a0 00 00 e1 a0 00 00 e1 a0 00 00 ? ..? .. ? ..? .. Feb 16 17:38:50 <[g2]> d3930 < 0xffff0 Feb 16 17:38:52 Looks right. Feb 16 17:38:55 yeah. Feb 16 17:38:59 Try this Feb 16 17:39:17 copy nor:0x60010+0xd3930 0x8000 Feb 16 17:39:35 Then boot -g 0x8000 Feb 16 17:40:07 <[g2]> boots fine until the rootfs Feb 16 17:40:22 Ah. then there is nothing wrong with the kernel image. Feb 16 17:40:36 <[g2]> I knew that Feb 16 17:40:38 OK. Reboot, if you will and we'll do another test. Feb 16 17:40:47 [g2]: You did, but I didn't. Feb 16 17:41:02 At the prompt, Feb 16 17:41:21 apex> checksum nor:0x60010+0xd3930 Feb 16 17:41:39 apex> checksum 0x8000+0xd3930 Feb 16 17:42:15 <[g2]> apex> checksum nor:0x60010+0xd3930 Feb 16 17:42:15 <[g2]> apex> checksum 0x8000+0xd3930 Feb 16 17:42:15 <[g2]> apex> Feb 16 17:42:20 The results should be the same Feb 16 17:42:31 <[g2]> checksum doesn't print anything Feb 16 17:42:39 Oh. Is APEX in flash? Feb 16 17:42:46 <[g2]> no, RAM Feb 16 17:43:08 OK. Rebuild it and change the config_cmd_checksum option in the config file. Feb 16 17:43:12 Then, reload it. Feb 16 17:48:11 <[g2]> apex> checksum nor:0x60010+0xd3930 Feb 16 17:48:11 <[g2]> crc32 0x9b9b573f (2610648895) over 866608 (0xd3930) bytes Feb 16 17:48:11 <[g2]> apex> checksum 0x8000+0xd3930 Feb 16 17:48:11 <[g2]> crc32 0x2d4e8640 (760120896) over 866608 (0xd3930) bytes Feb 16 17:48:11 <[g2]> apex> Feb 16 17:48:33 <[g2]> now we know the why Feb 16 17:48:37 <[g2]> or how come Feb 16 17:48:55 <[g2]> actually..... I need to copy first Feb 16 17:49:01 <[g2]> hold on.... sorry Feb 16 17:49:26 <[g2]> take that back is was automatically copied Feb 16 17:51:49 <[g2]> apex> copy nor:0x60010+0xffff0 0x00008000 Feb 16 17:51:49 <[g2]> 1048560 bytes transferred Feb 16 17:51:49 <[g2]> apex> checksum 0x8000+0xd3930 Feb 16 17:51:49 <[g2]> crc32 0x9b9b573f (2610648895) over 866608 (0xd3930) bytes Feb 16 17:51:49 <[g2]> apex> Feb 16 17:52:12 <[g2]> Ok my guess is the second copy is stomping on the kernel Feb 16 17:52:55 <[g2]> Hmmm... that didn't hold too much water Feb 16 17:53:30 .. so what the hell are you guys doing? :) Feb 16 17:53:56 <[g2]> TekGecko, testing a bootloader running from RAM for the nslu2 Feb 16 17:54:30 Ah. Feb 16 17:54:35 .. not that I know what that is :) Feb 16 17:59:44 <[g2]> TekGecko, do you run a PC with linux ? Feb 16 18:01:15 My home machine is a Windows box Feb 16 18:01:21 .. but I administer several linux servers. Feb 16 18:01:23 RHEL3 and Fbsd. Feb 16 18:01:51 [g2]: I am not following what you did. Feb 16 18:02:01 <[g2]> TekGecko, think grub, lilo Feb 16 18:02:04 Dualbooting is a real pita and VMware dosent work all that well... I like both environments, its a pain in the ass having to pick. Feb 16 18:02:09 Heh. Feb 16 18:02:19 if VMware was a little better id do it. Feb 16 18:02:24 Though im tempted to start dualbooting again. Feb 16 18:02:38 <[g2]> beewoolie, On reboot the kernel is copied into memory by the default config right ? Feb 16 18:02:39 What disto do you run? Feb 16 18:02:52 apex> printenv Feb 16 18:03:01 It will show the startup command. Feb 16 18:03:20 <[g2]> apex> printenv Feb 16 18:03:20 <[g2]> cmdline *= console=ttyS0,115200 root=/dev/slug rootfstype=ext2,jffs initrd=0x01000000,10m Feb 16 18:03:20 <[g2]> startup *= copy nor:0x60010+0xffff0 0x00008000;copy nor:0x160010+0x69fff0 0x01000000; Feb 16 18:03:20 <[g2]> bootaddr *= 0x00008000 Feb 16 18:03:26 that's the default put into the binary during the build. It can be changed with the environment. Feb 16 18:03:28 <[g2]> the first copy nor: Feb 16 18:03:43 Those copies should be OK. Feb 16 18:03:50 <[g2]> *should* Feb 16 18:04:03 Did you find that the kernel image in ram didn't match the flash image? Feb 16 18:04:14 <[g2]> exactly Feb 16 18:04:29 Try comparing the root filesystem images in memory and flash. Feb 16 18:06:47 <[g2]> that looks identical Feb 16 18:07:14 [g2]: OK. let's think about this. How is it that part of the kernel is being clobbered. Feb 16 18:07:16 <[g2]> given the lenght of the crc32 (I thought it was only good for 4MB) Feb 16 18:07:28 I suppose it would be helpful to have a compare function. Feb 16 18:07:47 [g2]: for one thing, the kernel is only 800K. Feb 16 18:08:20 [g2]: for another, it doesn't matter how long the kernel is. the CRC might not be strong at that length, but it still works. Feb 16 18:08:22 <[g2]> well the flash is padded out with probably ff for the rest Feb 16 18:08:30 Shouldn't matter. Feb 16 18:08:37 We're only checksum'ing the real data. Feb 16 18:08:42 <[g2]> right Feb 16 18:09:01 What doesn't make sense to me is that this works fine for dyoung. Feb 16 18:09:04 Same hardware. Feb 16 18:09:18 <[g2]> well he is running from flash Feb 16 18:09:28 He ran from ram, too Feb 16 18:10:03 It seems like we need a compare function. Let me see if I have one written... Feb 16 18:10:41 <[g2]> I think we can find where it end pretty easily with the checksum Feb 16 18:10:51 Actually, there is one already. Enable config_cmd_compare Feb 16 18:11:12 You can do that with a binary search, yes. Or you can use the elevator Feb 16 18:11:23 Your choice. Feb 16 18:11:35 <[g2]> I enabled fill while I was at it :) Feb 16 18:12:13 good thinking. Feb 16 18:12:36 I like a good mystery. Feb 16 18:13:29 <[g2]> so what the syntax for the config_cmd_compare ? compare 0x80000+0x... 0x.... Feb 16 18:13:39 apex> help compare Feb 16 18:17:35 <[g2]> apex> compare 0x8000+0xd3930 nor:0x60010+0xd3930 Feb 16 18:17:35 <[g2]> regions differ 0x00 != 0xf7 at 374976 (0x5b8c0) Feb 16 18:17:35 <[g2]> apex> Feb 16 18:18:36 <[g2]> that's a totaly unstellar place to differ Feb 16 18:18:52 yeah. very random Feb 16 18:19:23 <[g2]> 366.1875 K into the image Feb 16 18:19:50 * [g2] reboot to try again Feb 16 18:19:58 is it always the same place? Feb 16 18:20:27 * [g2] points to the previous message (this is the first check) Feb 16 18:20:51 That is very unexpected, yeah. Feb 16 18:21:23 I wonder if that is a problem with the flash timing. Feb 16 18:21:45 <[g2]> or memory timing Feb 16 18:21:51 Yeah. Feb 16 18:21:56 <[g2]> but that was the voice of reason Feb 16 18:22:04 Except that I'm not changing the memory timing. Feb 16 18:22:12 What speed did you program GPIO15 to be? Feb 16 18:22:18 33MHz Feb 16 18:22:29 <[g2]> ohhh Feb 16 18:22:30 Same as redboot Feb 16 18:22:35 Ah okay. Just checking Feb 16 18:22:46 <[g2]> apex> compare 0x8000+0xd3930 nor:0x60010+0xd3930 Feb 16 18:22:46 <[g2]> 866608 bytes the same Feb 16 18:22:46 <[g2]> apex> Feb 16 18:22:51 hrmmm Feb 16 18:22:56 Works this time? Feb 16 18:23:00 that's more worrying IMO Feb 16 18:23:05 yes it is. Feb 16 18:23:26 * [g2] tries from a hard reset Feb 16 18:23:27 intermittent errors are a real PITA to find and fix Feb 16 18:23:44 Well, I could make the copy code to a verify. Feb 16 18:24:31 Hmm. Feb 16 18:24:41 Would you mind doing it again/ Feb 16 18:24:42 ? Feb 16 18:24:50 <[g2]> apex> compare 0x8000+0xd3930 nor:0x60010+0xd3930 Feb 16 18:24:51 <[g2]> regions differ 0x00 != 0x49 at 378176 (0x5c540) Feb 16 18:24:51 <[g2]> apex> Feb 16 18:25:12 hmm Feb 16 18:25:20 what happens if you do the compare again without rebooting? Feb 16 18:25:25 does it break at the same point? Feb 16 18:25:45 Interesting that the memory byte is always zero. Feb 16 18:25:49 <[g2]> yeah Feb 16 18:26:05 You can also see what happens when you reverse the operands. Feb 16 18:26:08 <[g2]> like a refresh issue/ timing Feb 16 18:26:10 Or do a dump on that region. Feb 16 18:26:14 yeah about it being the same? Feb 16 18:26:48 <[g2]> apex> compare nor:0x60010+0xd3930 0x8000+0xd3930 Feb 16 18:26:49 <[g2]> regions differ 0x49 != 0x00 at 378176 (0x5c540) Feb 16 18:26:52 It is easy to check on the timing registers. I thought that I'd setup them the same as redboot. Feb 16 18:27:01 that's good! Feb 16 18:27:14 that suggests that it happens during the copy. Feb 16 18:27:18 yeah Feb 16 18:28:05 <[g2]> so the question is why is the second copy good, and the first copy bad Feb 16 18:28:17 bad timing on writes? Feb 16 18:28:37 <[g2]> because the 6MB+ ramdisk area is copied fine Feb 16 18:28:44 I see something that could be the culprit. Feb 16 18:29:01 WRITE_ONE (index, CMD (ReadArray)); Feb 16 18:29:03 memcpy (pv, (void*) index, available); Feb 16 18:29:12 That's what I do when the user asks to read from flash. Feb 16 18:29:22 It might be necessary to wait a little bit in between. Feb 16 18:29:48 It isn't on any other platform I've worked with, but perhaps we have something odd here. Feb 16 18:30:30 We could try putting a READ_ONE (index) right after the WRITE_ONE Feb 16 18:31:16 It shouldn't matter, as I say, but I haven't examined the flash timing very closely. I have seen too tight flash timing before. Feb 16 18:32:33 [g2]: You could also try re-enabling the write buffer. Look in initialize.c in the mach-ix42x Feb 16 18:32:55 I'm explicitly disabling the write buffer and the instruction cache. Feb 16 18:34:30 * [g2] has another idea Feb 16 18:34:38 share Feb 16 18:35:30 <[g2]> reversing the copies on the cmdline Feb 16 18:36:00 <[g2]> what's quite odd to me is that the second copy works fine which is 6MB+ Feb 16 18:36:56 <[g2]> If it's an initialization issue somewhere the first copy will still fail, but the kernel copy will be ok Feb 16 18:38:06 <[g2]> however, that really doesn't explain why it moves around a little with the kernel copy Feb 16 18:39:12 evening guys Feb 16 18:39:17 prpplague: eve Feb 16 18:39:28 [g2]: as you might guess, I'm not satisfied with that answer Feb 16 18:39:52 beewoolie: hehe, trying to get apex booting on my samsung board (and juicebox) Feb 16 18:40:03 <[g2]> well it's more of a question than an answer Feb 16 18:40:05 crap Feb 16 18:40:14 spammer has been at the wiki Feb 16 18:40:21 gah. time to clean up Feb 16 18:40:23 prpplague: I'm impressed. I usually like to fix one thing before opening another can Feb 16 18:40:29 Tiersten: argh i hate that Feb 16 18:40:49 Tiersten: bummer. Feb 16 18:40:55 beewoolie: hehe, the 79520 is work, this is hobby Feb 16 18:41:23 [g2]: Are you willing to try the write buffer change? Feb 16 18:41:29 beewoolie: i've been doing userland stuff for awhile, trying to get more into the low level stuff Feb 16 18:41:49 <[g2]> beewoolie, I'm looking for it now Feb 16 18:43:00 <[g2]> /* Disable write buffer coalescing */ Feb 16 18:43:00 <[g2]> #if 1 Feb 16 18:43:00 <[g2]> { Feb 16 18:43:11 <[g2]> that change ? to #if 0 Feb 16 18:43:23 That's different. Feb 16 18:43:34 Just after that. Feb 16 18:43:36 <[g2]> "bic r0, r0, #(1<<4)\n\t" /* Disable write buffer */ Feb 16 18:43:39 Right. Feb 16 18:43:52 <[g2]> just comment it out Feb 16 18:43:58 Right. Feb 16 18:46:10 <[g2]> compare nor:0x60010+0xd3930 0x8000+0xd3930 Feb 16 18:46:10 <[g2]> regions differ 0x39 != 0x00 at 373376 (0x5b280) Feb 16 18:46:39 <[g2]> we're batting 100% on the Zero's though Feb 16 18:48:09 anyone recommend a url/doc with some good info on debugging via jtag, i'd like to see how that is done in the code Feb 16 18:48:11 <[g2]> hmmm, but copy the second time still works Feb 16 18:50:29 ka6sox-away: this is the unit that is suppose to use the 2232 chip - http://www.usbgear.com/USBG-232FT-1.html Feb 16 18:50:34 you guys are so cool. Feb 16 18:51:02 <[g2]> dyoung-web, why is that ? Feb 16 18:51:18 [g2]: Do you have a parallel port JTAG dongle? Feb 16 18:51:26 <[g2]> Tiersten, nod. Feb 16 18:51:34 You guys are REAL hackers. Feb 16 18:51:51 What happens if you try to read the RAM and flash via JTAG? Feb 16 18:52:08 I've been following the log all day, Youre my Hero. ;-) Feb 16 18:52:13 <[g2]> Tiersten, I'm not wired for JTAG on the slug, but soon ! Feb 16 18:52:41 <[g2]> beewoolie's my Hero :) Feb 16 18:52:46 hehe Feb 16 18:52:50 <[g2]> for the day anyway :) Feb 16 18:53:01 [g2]: and you've replaced redboot? brave... :) Feb 16 18:53:29 did the write-buffer change work? Feb 16 18:53:33 <[g2]> Tiersten, I'm just running from RAM right now Feb 16 18:54:15 <[g2]> If I had more than one serial enabled slug, I'd have replaced it a couple days ago Feb 16 18:54:48 * prpplague needs to get a slug Feb 16 18:54:55 <[g2]> and since ka6sox-fedex is sending back the FatSlug with JTAG enable I can be a little patient Feb 16 18:54:58 I think I'm gonna serial enable another slug today. Feb 16 18:55:26 <[g2]> dyoung-web, Don't you think APEX is Sweet ? Feb 16 18:55:30 I need to twiddle unslung-4 some, but I also want to play Apex... Feb 16 18:55:41 I think apex is the best thing since sliced bread. Feb 16 18:55:50 <[g2]> ~praise beewoolie Feb 16 18:55:55 its written in such a way that I can read it. Feb 16 18:56:42 dyoung-web: That's a very nice compliment Feb 16 18:56:51 Did you read the overview? Feb 16 18:59:01 <[g2]> beewoolie, do you flush the cache after disabling the mmu ? Feb 16 18:59:21 <[g2]> both I and D ? Feb 16 18:59:44 I, um, I think I broke that. Feb 16 19:00:03 I reordered that function and it looks like that that's in the wrong order. Feb 16 19:00:18 Wait, it shouldn't matter. Feb 16 19:00:29 I flush the cache right before I disable the MMU. Feb 16 19:01:27 <[g2]> it might matter a couple of instructions worth Feb 16 19:01:31 And I do it again, for good measure, after relocate. Feb 16 19:01:54 it could. Except that the cache is flushed again in relocate. Feb 16 19:02:18 You could move the disable MMU code above all of that CP15 stuff. Feb 16 19:03:03 Besides, the address isn't near the apex code. Feb 16 19:03:19 Did you try the write buffer change? Feb 16 19:03:29 <[g2]> Yeah they failed. Feb 16 19:03:39 OK. That's good, IMHO. Feb 16 19:03:57 <[g2]> 30 minutes ago I posted the result Feb 16 19:04:06 <[g2]> ok 27 Feb 16 19:04:49 <[g2]> The overview is nice! Feb 16 19:05:09 Ah. I see it now. Feb 16 19:05:27 It was overwhelmed by the walawala. Feb 16 19:12:25 [g2]: I checked the flash timing. It's set to the slooooowest. Feb 16 19:18:00 Is most of the development stuff you guys do in linux? Feb 16 19:18:09 <[g2]> nod. Feb 16 19:18:16 <[g2]> for me Feb 16 19:19:33 I've been wanting to get in to device hacking for a while, but not sure exactally where to start. Feb 16 19:20:30 TekGecko: It's all slug baby Feb 16 19:20:46 You can't beat an $80 dev system. Feb 16 19:21:04 Slug? Feb 16 19:21:10 ...plus the hundreds you'll pour into the 'incedentals'. Feb 16 19:21:16 nslu2 => slug Feb 16 19:21:35 LinkSys product with xscale cpu, ethernet, and two usb2.0 ports Feb 16 19:22:32 nslu2 is a processor? Feb 16 19:22:43 Sorry, im clueless to what you're talking about at the moment. :P Feb 16 19:22:55 TekGecko: a network storage device Feb 16 19:23:09 TekGecko: has an ixp xscale processor Feb 16 19:23:10 Oh. Feb 16 19:23:16 http://www.linksys.com/products/product.asp?grid=35&scid=43&prid=640 Feb 16 19:23:59 I meant device hacking in general, specifically jtag stuff. Feb 16 19:25:40 TekGecko: hehe, not like jumping in with both feet with stuff Feb 16 19:26:10 TekGecko: you got a jtag dongle to play with? Feb 16 19:26:27 prpplague, I dont mind diving right in - its just where to start. Feb 16 19:26:34 prpplague, I do - but its not with me at the moment. Feb 16 19:26:54 <[g2]> On a different note, Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,3) Feb 16 19:26:55 This is the one I built. http://wiki.buici.com/twiki/bin/view/Main/SimpleJTAG Feb 16 19:27:13 But like, where the hell do you even start on some of this stuff? Feb 16 19:27:15 heh Feb 16 19:27:26 TekGecko: hehe, i'm sure you can get alot of advice here as well as in the assorted embedded channels such as #elinux #handhelds.org Feb 16 19:27:27 [g2]: That's a problem with the root filesystem, obviously. Usually the root= is wrong or a driver is missing. Feb 16 19:27:29 Like great, a JTAG lets you dump a rom - what do you do from there? Feb 16 19:27:43 TekGecko: hehe, jtag is much more than that Feb 16 19:28:35 Well like the Juicebox for example. Feb 16 19:28:41 Where do you even start on a project like that. Feb 16 19:28:47 TekGecko: jtag can be used to do manufacturing tests, program devices, and debugging Feb 16 19:29:24 TekGecko: i'm sure you'll get a variety of methods described here Feb 16 19:29:31 TekGecko: but like the juicebox Feb 16 19:29:52 TekGecko: i usually order a dev board with similiar hardware as to what i'm hacking Feb 16 19:30:33 TekGecko: that way you have a reference to work with Feb 16 19:31:23 http://anyway.no-ip.org:8080/ep/44B0db/44B0db.htm Feb 16 19:32:43 Interesting. Feb 16 19:32:55 But how does that help you hack the juicebox for example? Feb 16 19:33:01 TekGecko: once you have a known working platform with docs you can make comparisons as to how the hack platform will work Feb 16 19:33:01 Did you load the ROM off a juicebox on to there? Feb 16 19:33:19 TekGecko: first you normally get the schematics for the dev board Feb 16 19:33:40 TekGecko: and most manufacturers like emsoft don't deviate from the reference design very much Feb 16 19:33:50 TekGecko: second, you normally get working code Feb 16 19:34:41 TekGecko: like the juice box case, i created a working jtag application first on the dev board, then once i knew it was working, i could use it on the juicebox Feb 16 19:35:15 I thought jtag software was all the same? Feb 16 19:35:24 Why would you have to write something special for the juicebox Feb 16 19:35:49 TekGecko: each device that supports jtag has different functions Feb 16 19:36:01 TekGecko: which are described in a file called a BSDL file Feb 16 19:36:12 TekGecko: Boundry Scan Description Language Feb 16 19:36:47 Ok, so there is no 'one jtag software' that dumps all chips. Feb 16 19:36:52 There are also extensions to JTAG that are not compatible. EJTAG, IIRC, for MIPS. Feb 16 19:36:53 TekGecko: some of the more robust jtag applications like jtagtools can use the bsdl file directly Feb 16 19:36:53 .. er, well interfaces. Feb 16 19:37:14 TekGecko: that is correct Feb 16 19:37:19 prpplague: I don't think jtagtools uses BSDL files. Feb 16 19:37:22 <[g2]> beewoolie, THX for the help Feb 16 19:37:29 [g2]: What, does it work? Feb 16 19:37:35 beewoolie: it comes with a tool to convert the bsdl into a header file Feb 16 19:37:44 prpplague: I wasn't successful with that tool. Feb 16 19:37:45 <[g2]> not yet, but I've got a work-around Feb 16 19:37:54 [g2]: The reordering? Feb 16 19:38:03 <[g2]> just load it a second time Feb 16 19:38:07 <[g2]> copy Feb 16 19:38:09 :| Mabye I'm better off not trying to learn, heh. Feb 16 19:38:21 I'll add an option to verify the copy. It should force it to work, too. Feb 16 19:38:24 This is some complicated shit, heh. Feb 16 19:38:28 TekGecko: hehe, depends on where you want to go with your tech carrier Feb 16 19:38:41 Well, I dont plan on doing anything embeded. Feb 16 19:38:50 TekGecko: What's complex is that there are lots of pieces. some better than others. the only way to learn is to play. Feb 16 19:38:57 True. Feb 16 19:39:02 Its just the big question of where to start. Feb 16 19:39:15 prpplague: carrier? Like aircraft? Feb 16 19:39:17 <[g2]> TekGecko, what are you most interested in ? Feb 16 19:39:27 beewoolie: yea yea, i don't spell well Feb 16 19:39:39 TekGecko: Did you ever ask: "I've got all of the legos. Where do I start?" Feb 16 19:39:56 s/the/these/ Feb 16 19:40:06 TekGecko: my suggestion is for you to start with something that is already partially supported Feb 16 19:40:29 Well like hacking Tivos for example. Feb 16 19:40:36 Fairly simplistic as its basically a computer Feb 16 19:40:40 <[g2]> S1 or S2 Feb 16 19:40:44 TekGecko: yea, or ruxscreen, or webpal Feb 16 19:40:47 making modifications and learning it was simple since it was running linux and such. Feb 16 19:40:48 TekGecko: What works for me is to have a goal in mind. It might be modest, but at least I've got something I want to do. Feb 16 19:41:22 true, but what skills do you need to do it is the question though Feb 16 19:41:29 You'll learn them. Feb 16 19:41:40 TekGecko: yea, you learn, hehe Feb 16 19:41:45 It's important to be ok with failure. Feb 16 19:42:03 <[g2]> very important Feb 16 19:42:09 Heck, I salted my first slug. Feb 16 19:42:10 beewoolie: hehe, words well spoken after my day at the office today, hehe Feb 16 19:42:19 ;-) Feb 16 19:42:26 <[g2]> and my day with APEX :) Feb 16 19:42:30 <[g2]> HAH Feb 16 19:42:30 I've worked for a very wise fellow. Feb 16 19:42:45 He asked everyone in the top ranks to go out and make a mistake. A big mistake. Feb 16 19:42:49 Then clean it up. Feb 16 19:42:51 * [g2] is very happy with APEX Feb 16 19:42:54 he was serious. Feb 16 19:43:15 [g2]: Does it boot now? Feb 16 19:43:33 <[g2]> no with the mtdblocks Feb 16 19:43:41 <[g2]> it's contained though Feb 16 19:44:07 <[g2]> beewoolie, ever hear the jack welch story ? Feb 16 19:45:17 <[g2]> There's a bunch of Senior VPs working for jack (former CEO of GE) and this one guy winds up blowing $250 M on a project that's a total failure over a year Feb 16 19:45:45 <[g2]> One of the Senior VPs says to jack "Hey aren't you going to fire his a**" Feb 16 19:46:13 Interesting you mention GE. This guy used to work for GE. he was a superstart. Feb 16 19:46:18 TekGecko: hehe, i'd been doing linux for about 2 years before i got my first job doing embedded linux Feb 16 19:46:21 <[g2]> jack said "Fire him, hell why would I do that, I just paid for his freshman year" Feb 16 19:46:23 he quit because GE treated him poorly. Feb 16 19:46:55 prpplague: You're lucky. It took me closer to ten years. Feb 16 19:46:56 <[g2]> well GE is quite a big company Feb 16 19:47:20 I forget the name of the guy he worked for. I should remember as he was famous. Feb 16 19:47:28 could have been JW for all I know. Feb 16 19:47:42 beewoolie: yea well i had a trial by fire Feb 16 19:47:59 <[g2]> today ? Or some other time Feb 16 19:48:02 beewoolie: http://www.linuxdevices.com/news/NS8485254374.html Feb 16 19:48:27 beewoolie: that project just about killed me Feb 16 19:49:26 A little out of the price-point now, eh? Feb 16 19:50:07 Looks like a nice small package, though. Feb 16 19:50:10 beewoolie: yea, back then it was good though Feb 16 19:50:21 beewoolie: i screwed up with the powersupply Feb 16 19:50:21 [g2], did you work out your rootfs issue earlier? Feb 16 19:50:22 did it sell? Feb 16 19:50:30 beewoolie: alost 12,000 units Feb 16 19:50:34 prpplague: did you design the PS? Feb 16 19:50:39 beewoolie: yea Feb 16 19:50:50 But it looks like it uses a wall wart. Feb 16 19:50:56 beewoolie: but not until after we had shipped 2,000 units Feb 16 19:51:13 beewoolie: had an internal voltage regulator that overheated Feb 16 19:51:16 You put the PS inside and it was broken? Feb 16 19:51:19 Ah. Feb 16 19:53:04 beewoolie: http://www.linuxdevices.com/files/misc/tcsx-1-inside.jpg Feb 16 19:53:14 beewoolie: seen the regulator next to the cpu Feb 16 19:53:20 s/seen/see Feb 16 19:54:24 My my my. That's a dense board. Feb 16 19:54:41 beewoolie: thats what made me sick of x86 Feb 16 19:54:46 Uh hum. Feb 16 19:55:07 I used an x86 PC104 board on a project. It was reasonably solid, but a PITA. Feb 16 19:56:02 How did you fix the regulator temp problem? Feb 16 19:56:26 beewoolie: put the regulator pins on a header Feb 16 19:56:39 beewoolie: then moved the regulator to the outide case Feb 16 19:56:53 outside Feb 16 19:56:58 got it Feb 16 19:57:52 beewoolie: also bumped up the regulator up to a version with a higher current rating Feb 16 19:58:10 Don't you hate it when make clean doesn't really do it's job? Feb 16 19:58:24 hehe, yea Feb 16 19:59:47 prpplague: Good lesson, the regulator thing. Feb 16 20:00:00 beewoolie: hehe, yea Feb 16 20:00:12 What's the chip right of the CPU? Feb 16 20:00:16 beewoolie: like i said earlier today, i like to learn the hardway Feb 16 20:00:28 I can tell. Feb 16 20:00:30 <[g2]> dyoung-web, I haven't fully worked out the rootfs issue yet Feb 16 20:00:36 beewoolie: i/o chip set Feb 16 20:00:43 [g2]: I thought it boots now. Feb 16 20:00:52 beewoolie: has ide, floppy, uart, lpt, ps/2 Feb 16 20:00:59 prpplague: That's the crappy part about x86. Feb 16 20:01:11 beewoolie: yea Feb 16 20:01:17 Way more value in the SoCs. Feb 16 20:01:23 <[g2]> beewoolie, no, it boots like it did a couple days ago if switchbox is in there Feb 16 20:01:30 beewoolie: and then add all that legacy bios #@%^#%^ Feb 16 20:01:34 The Sharp CPUs have loads in them and sell for $15. Feb 16 20:01:55 [g2]: So this is the JFFS alignment issue. Feb 16 20:01:58 beewoolie: we spent more time debugging the bios than any other part Feb 16 20:02:20 You didn't buy a BIOS? Feb 16 20:02:36 <[g2]> beewoolie, nod. Feb 16 20:02:41 rootfstype=jffs2 Feb 16 20:02:51 <[g2]> dyoung-web, I did that Feb 16 20:03:25 beewoolie: yea, we bought it, but there was a ton of customization Feb 16 20:03:39 <[g2]> dyoung-web, where is the kernel getting the partition data from ? Feb 16 20:03:55 [g2]: where is the jffs2 filesystem? Is it at the start of a partition? Feb 16 20:04:17 <[g2]> beewoolie, nod. mtdblock4 Feb 16 20:04:47 [g2]: and the redboot partition table has that partition, right? Feb 16 20:05:23 from the fis partition table. Feb 16 20:05:33 <[g2]> Creating 6 MTD partitions on "IXP4XX-Flash0": Feb 16 20:05:33 <[g2]> 0x00000000-0x00040000 : "RedBoot" Feb 16 20:05:33 <[g2]> 0x00040000-0x00060000 : "SysConf" Feb 16 20:05:33 <[g2]> 0x00060000-0x00160000 : "Kernel" Feb 16 20:05:33 <[g2]> 0x00160000-0x00800000 : "Ramdisk" Feb 16 20:05:34 <[g2]> 0x001a0000-0x007e0000 : "Flashdisk" Feb 16 20:05:36 <[g2]> 0x007e0000-0x00800000 : "FIS directory" Feb 16 20:05:38 <[g2]> i2c /dev entries driver Feb 16 20:05:40 <[g2]> LOADED Xicor x1205 RTC Dvr v0.9.3.3NPW Feb 16 20:05:42 <[g2]> NET: Registered protocol family 2 Feb 16 20:05:44 It needs to be in the redboot partition table, or the kernel can't see it. Feb 16 20:05:54 Yes, it is. Feb 16 20:06:01 its wedged into the last block. Feb 16 20:06:11 Is switcher in mtdblock3? Feb 16 20:06:13 <[g2]> FIS directory Feb 16 20:06:15 switchbox Feb 16 20:06:25 2 Feb 16 20:06:30 TekGecko: point being, there is alot to learn Feb 16 20:06:36 <[g2]> 3 Feb 16 20:06:46 right. And does it load drivers? Feb 16 20:06:46 TekGecko: just gotta start tinkering Feb 16 20:06:49 sorry fat fingers Feb 16 20:06:50 3 Feb 16 20:06:52 ;-) Feb 16 20:07:06 <[g2]> no drivers loaded Feb 16 20:07:16 BTW, it works for me. Feb 16 20:07:17 <[g2]> except the Intel module Feb 16 20:07:40 So you're telling me that console=ttyS0 rootfstype=jffs2 root=/dev/mtdblock4 fails to boot. Feb 16 20:07:41 <[g2]> but that's switchbox 4.0 right Feb 16 20:07:54 no. Feb 16 20:08:13 by doing what beewoolie just said, I'm ignoring switchbox Feb 16 20:08:39 That's the idea. Honestly, I don't know the details of switch box. Feb 16 20:08:55 the kernel should mount a jffs2 partition, though, as long as all drivers are in place. Feb 16 20:09:03 It does for me. Feb 16 20:09:29 dyoung-web: [g2] also has problems just copying the kernel from flash to memory. Feb 16 20:09:39 <[g2]> apex> boot console=ttyS0,115200 root=/dev/mtdblock4 rootfs=jffs2 Feb 16 20:09:39 <[g2]> Booting kernel at 0x00008000... Feb 16 20:09:39 <[g2]> Uncompressing Linux........................................................... done, booting the kernel. Feb 16 20:09:39 <[g2]> Linux version 2.6.9 (tom@gentoo2) (gcc version 3.4.3) #1 Sat Feb Feb 16 20:09:49 <[g2]> NET: Registered protocol family 1 Feb 16 20:09:49 <[g2]> Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,4) Feb 16 20:10:05 That sounds like a missing driver. Feb 16 20:10:10 Let me check on something... Feb 16 20:10:26 weird. Feb 16 20:10:34 I'm hungry. Feb 16 20:10:36 back later. Feb 16 20:10:42 <[g2]> dyoung-web, nite, Feb 16 20:10:57 doh Feb 16 20:11:40 [g2]: isn't is rootfstype=jffs2? Feb 16 20:12:19 <[g2]> ahhh.... Feb 16 20:12:57 <[g2]> it's supposed to be Feb 16 20:15:03 * [g2] hugs beewoolie Feb 16 20:15:13 <[g2]> MY BAD on the rootfs= Feb 16 20:16:07 <[g2]> beewoolie, THX Feb 16 20:16:16 [g2]: Was that it? Feb 16 20:16:23 <[g2]> that was exactly it Feb 16 20:16:39 Nice. Feb 16 20:16:56 [g2]: If I were you, I wouldn't flash it until we get the copy problem resolved. Feb 16 20:16:59 <[g2]> yeah, that one didn't make much sense, but now it does :) Feb 16 20:17:13 <[g2]> right, I won't Feb 16 20:17:22 <[g2]> or until I have JTAG Feb 16 20:17:25 [g2]: One thing I'd like to know is if this is a read error from flash or a write error to ram. Feb 16 20:17:39 <[g2]> me too Feb 16 20:18:04 I'll make a change to APEX that will help discover that. Feb 16 20:18:25 <[g2]> can you make one more change for me ? Feb 16 20:18:47 <[g2]> or maybe I'll make it myself Feb 16 20:19:18 <[g2]> I'll change the compare funtion to take another parameter which is the number of occurances Feb 16 20:19:38 <[g2]> so we can automatically check for like < 50 diffs Feb 16 20:27:45 [g2]: thats what I'm going to add. Feb 16 20:28:19 [g2]: You are welcome to hack APEX if you like ;-) Feb 16 20:31:55 <[g2]> beewoolie, I plan on hacking APEX and submitting patches to you :) Feb 16 20:32:16 Don't be sad if I implement the feature a different way. Feb 16 20:32:31 <[g2]> Oh I won't be sad at all Feb 16 20:32:34 I'm almost done with it. Feb 16 20:32:48 <[g2]> that's good, I went and got a snack Feb 16 20:32:55 <[g2]> and some water Feb 16 20:34:17 <[g2]> I only care to be smart enough to eventually understand something and not to piss-off the ppl I like working with Feb 16 20:35:08 <[g2]> I've got ideas and a share a bunch some work, some don't it's all one be learning process Feb 16 20:36:24 I try not to be too hard-core either. Feb 16 20:36:47 I've met plenty of stinkers online. Good to work with non-stinkers. Feb 16 20:36:59 It's written, I need to test. Feb 16 20:37:00 <[g2]> yep Feb 16 20:37:23 <[g2]> that's the compare on copy support ? Feb 16 20:37:37 That's the compare with more than one differences support. Feb 16 20:38:04 compare on copy is a little trickier. We need to compare on read as well as write and then report when there are deviations. Feb 16 20:38:56 I'm deciding whether or not I want to use a second buffer or a checksum. Feb 16 20:41:01 * [g2] would think about the second buffer, Initially, I'd lean on no second buffer because if you are copying large areas it might cause more problems than it's worth Feb 16 20:42:28 [g2]: I copy is 1k chunks. Feb 16 20:42:33 s/is/in/ Feb 16 20:42:47 <[g2]> so an extra 1k isn't bad Feb 16 20:42:47 Extra buffer isn't really much of a hassle, but it makes the function messier. Feb 16 20:42:51 Right. Feb 16 20:43:22 One of the odd side-effects of the APEX design is that I don't move from one device to another without an intermediate. Feb 16 20:43:47 If I implemented an mmap interface, I could. then, I'd only be a couple of K away from a full blown linux kernel. Feb 16 20:43:59 ;-) Feb 16 20:44:03 <[g2]> no memory-to-memory moves :) Feb 16 20:44:14 [g2]: bug-count 1 Feb 16 20:44:24 [g2]: Every device has a read and a write function. Feb 16 20:44:31 copy reads from one and writes to the other. Feb 16 20:44:46 the abstraction makes the system very flexible. Feb 16 20:45:09 <[g2]> Oh I think it's fine Feb 16 20:45:17 it's fast enough. Feb 16 20:45:43 <[g2]> there's always dma Feb 16 20:46:08 One bug. Not bad. it seems to work. Feb 16 20:46:27 do you want it? Feb 16 20:46:34 <[g2]> sure Feb 16 20:46:39 Or would you rather have the verified copy, too. Feb 16 20:46:45 <[g2]> what's the bug or is that the one you fixed Feb 16 20:47:03 I had a strcmp and forgot to make it == 0. fixed. Feb 16 20:47:28 <[g2]> = 0 ? Feb 16 20:48:01 strcmp (a,b) == 0 for equality. It was strcmp (a,b) which is inequality. Feb 16 20:48:24 <[g2]> ah Feb 16 20:49:16 <[g2]> Is it a tiny change ? Feb 16 20:52:56 [g2]: 1.0.26 is available via ftp. Feb 16 20:53:39 It still takes several steps to release. I haven't added a target to do everything in one go. Feb 16 20:56:47 <[g2]> apex> compare nor:0x60010+0xffff0 0x00008000+0xffff0 Feb 16 20:56:47 <[g2]> regions differ 0xf7 != 0x00 at 374976 (0x5b8c0) Feb 16 20:56:47 <[g2]> apex> Feb 16 20:57:05 That seems like a familiar place. Feb 16 20:57:11 What about with -c 10 Feb 16 20:57:17 apex> help compare Feb 16 20:57:57 <[g2]> apex> compare -c 10 nor:0x60010+0xffff0 0x00008000+0xffff0 Feb 16 20:57:57 <[g2]> regions differ 0xf7 != 0x00 at 374976 (0x5b8c0) Feb 16 20:57:57 <[g2]> regions differ 0xb7 != 0x04 at 374977 (0x5b8c1) Feb 16 20:57:57 <[g2]> regions differ 0x92 != 0x5a at 374978 (0x5b8c2) Feb 16 20:57:57 <[g2]> regions differ 0x0d != 0x0f at 374979 (0x5b8c3) Feb 16 20:57:58 <[g2]> regions differ 0xc1 != 0x9d at 374980 (0x5b8c4) Feb 16 20:58:00 <[g2]> regions differ 0x13 != 0x2c at 374981 (0x5b8c5) Feb 16 20:58:02 <[g2]> regions differ 0xbf != 0x00 at 374982 (0x5b8c6) Feb 16 20:58:04 <[g2]> regions differ 0x6c != 0x0c at 374983 (0x5b8c7) Feb 16 20:58:06 <[g2]> regions differ 0x98 != 0x41 at 374984 (0x5b8c8) Feb 16 20:58:09 <[g2]> regions differ 0xa0 != 0x1a at 374985 (0x5b8c9) Feb 16 20:58:25 That's kindofa lot Feb 16 20:58:40 <[g2]> all in sequence Feb 16 20:59:19 See if you can find an end of the sequence. It is a cache line? Feb 16 20:59:44 <[g2]> well 100 are bad I'm checking if it's all sequential Feb 16 21:00:04 [g2]: haven't added a more mode yet. Feb 16 21:01:59 <[g2]> regions differ 0x1e != 0x00 at 375036 (0x5b8fc) Feb 16 21:01:59 <[g2]> regions differ 0xd4 != 0x00 at 375037 (0x5b8fd) Feb 16 21:01:59 <[g2]> regions differ 0xef != 0x00 at 375038 (0x5b8fe) Feb 16 21:01:59 <[g2]> regions differ 0x0e != 0x00 at 375039 (0x5b8ff) Feb 16 21:01:59 <[g2]> regions differ 0xd0 != 0x00 at 379820 (0x5cbac) Feb 16 21:02:00 <[g2]> regions differ 0x54 != 0x00 at 379821 (0x5cbad) Feb 16 21:02:02 <[g2]> regions differ 0xd0 != 0x00 at 379822 (0x5cbae) Feb 16 21:02:23 Is that after a second boot? Feb 16 21:02:27 <[g2]> it's congiguous up until the 039, then there's skip Feb 16 21:02:48 Ah. Feb 16 21:02:48 <[g2]> second block ? Feb 16 21:03:11 It's definitely at a suspicious location. Feb 16 21:03:40 <[g2]> how so ? Feb 16 21:03:41 did you try inserting READ_ONE after the WRITE_ONE? Feb 16 21:03:49 <[g2]> no Feb 16 21:03:53 suspicious because of the 8ff ending. Feb 16 21:04:10 don't worry yet. I'll add the verify feature so we don't go chasing rabbits. Feb 16 21:04:26 * beewoolie celebrates. OPIE finished bulding. Feb 16 21:04:29 <[g2]> I'm not worried at all Feb 16 21:04:39 <[g2]> excellent! Feb 16 21:05:08 here's what I'm thinking for the verify function. Feb 16 21:05:25 I think it would be best to reread both the source and destination after the whole copy has been compelted. Feb 16 21:05:45 There is still the extra buffer, but it doesn't interfere with the copy. Feb 16 21:08:51 <[g2]> hmmm, it is interesting to note that the failure always seems to occur on a a paragraphs (0x10) boundary Feb 16 21:09:05 That is a cache line. Feb 16 21:09:54 Actually, I don't think it's a cache line. Feb 16 21:10:10 But I do think it is something structural. Feb 16 21:10:13 <[g2]> and except for Feb 16 21:10:16 <[g2]> regions differ 0xd0 != 0x00 at 379820 (0x5cbac) Feb 16 21:10:16 <[g2]> regions differ 0x54 != 0x00 at 379821 (0x5cbad) Feb 16 21:10:16 <[g2]> regions differ 0xd0 != 0x00 at 379822 (0x5cbae) Feb 16 21:10:16 <[g2]> regions differ 0x8c != 0x3c at 379823 (0x5cbaf) Feb 16 21:10:38 <[g2]> when it restarted after a bunch of contiguous errors Feb 16 21:10:44 If you run the diff again and again, it is exactly the same? Feb 16 21:10:56 <[g2]> the compare ? Feb 16 21:10:59 right. Feb 16 21:11:29 My plan is bogus because it won't tell us if the read failed or if the write failed. Feb 16 21:11:38 This verified copy is going to take some work. Feb 16 21:12:21 <[g2]> multiple execution looks the same Feb 16 21:12:30 Good. Feb 16 21:15:21 <[g2]> I think you have a bug in you count Feb 16 21:15:32 Perhaps. Feb 16 21:15:38 <[g2]> but it looks like only 80 bytes are different Feb 16 21:15:45 Though I counted it before and it wasOK. Feb 16 21:15:59 It works for 1 and 2 so I figured it was OK. Feb 16 21:16:30 <[g2]> works for 10, but not 100 Feb 16 21:16:55 <[g2]> maybe it does work ok Feb 16 21:18:04 OK. Here's the thing about the verification. It will be able to catch and fix read errors, but write errors are not going to be fixable. at least not for the time being. Feb 16 21:18:14 SDRAM isn't a problem, but flash is. Feb 16 21:18:56 do you think it should correct the copy if it can, or just bail out? Feb 16 21:18:57 <[g2]> well we're writing to SDRAM Feb 16 21:19:03 <[g2]> BAIL! Feb 16 21:19:27 I know, but the driver doesn't yet know the difference. It doesn't know if the device has to be erased before being rewritten. Feb 16 21:19:33 OK. Bail it is. Feb 16 21:20:21 <[g2]> I think this is rare, and only on the first copy Feb 16 21:20:56 <[g2]> it may be a hw problem Feb 16 21:21:20 that's what I think, but we have to be sure. Feb 16 21:23:13 <[g2]> when I get the other unit we can do more testing Feb 16 21:23:35 did ka6sox send it out? Feb 16 21:23:42 <[g2]> ka6sox-fedex, Feb 16 21:23:49 rite. Feb 16 21:23:51 <[g2]> that's where he was heading Feb 16 21:24:03 Drat Feb 16 21:24:06 <[g2]> well time for some sleep Feb 16 21:24:11 I was hoping he would be ka6sox-tsunami today. Feb 16 21:24:13 <[g2]> drat ? Feb 16 21:24:13 and he got in an accident getting your package to fedex. You should be ashamed. Feb 16 21:24:13 ;-) Feb 16 21:24:15 j/k Feb 16 21:24:46 <[g2]> maybe it's both :) Feb 16 21:25:16 I wish I could rmemeber what tsunami stood for. We spent an inordinate amount of time coming up with the acronym Feb 16 21:25:26 ... and measurement interface Feb 16 21:25:27 <[g2]> hey dyoung before I go to sleep I was screwing up the rootfs= cmd Feb 16 21:25:32 <[g2]> it's rootfstype= Feb 16 21:25:33 yeah I read that. Feb 16 21:25:37 <[g2]> cool Feb 16 21:25:41 I was going to make a snide comment. Feb 16 21:25:45 <[g2]> beewoolie's my hero and you are too Feb 16 21:25:57 * beewoolie looks for his cape Feb 16 21:26:02 <[g2]> LOL Feb 16 21:26:03 rootfstype=jffs2 Feb 16 21:26:11 heh Feb 16 21:26:34 I want a pro-wrestling mask for my superhero outfit. Feb 16 21:26:38 APEX does it correctly, now. Though it doesn't get the device right since it defaults to /dev/slug. Feb 16 21:26:51 dyoung: are you familiar with City of Heroes? Feb 16 21:26:59 Last night we worked out the bits to eliminate /dev/slug once and for all. Feb 16 21:27:00 aka COH-crack Feb 16 21:27:07 really? How? Feb 16 21:27:16 No not famliar with City of Heroes Feb 16 21:27:43 basically what you said earlier, root=/dev/ram0 rw init=/linuxrc . Feb 16 21:27:47 MMORPG where you get to be a superhero. The best part (and I mean it) is making your character. You get to choose lots of parameters. Feb 16 21:28:05 dyoung: I thought that the problem was that you couldn't add to the string? Feb 16 21:28:09 ~mmorpg Feb 16 21:28:30 No bot. Feb 16 21:28:32 we couldnt add to the string back in the early days; but we have the source now, so we can. Just n ever bothered to since it worked. Feb 16 21:28:42 Ah. Feb 16 21:28:47 )read: being lazy) Feb 16 21:28:57 IIWDFI Feb 16 21:29:11 Geez, i need a beewoolie acronym translator. Feb 16 21:29:23 MMORPG is easy. Hit google. Feb 16 21:29:29 <[g2]> when we used to play Quake at work my skin was usually female Feb 16 21:29:39 If It Works Don't Fix It Feb 16 21:30:00 [g2]: This is way better than that. Unfortunately, the game is kinda dull. Feb 16 21:30:00 <[g2]> Multi ... ... Role Playing Game Feb 16 21:30:12 Massively Multiplayer Online RPG Feb 16 21:30:30 I guessed online rpg... I figured multiuser was one of the m's Feb 16 21:30:30 <[g2]> we used to get 16 Quakers Feb 16 21:30:41 Heh. I like iiwdfi. Feb 16 21:30:45 food, brb Feb 16 21:30:50 I thought that Quakers didn't believe in violient games Feb 16 21:30:55 in case you go sleep, night [g2]. Feb 16 21:31:06 Hey, he's been to eat twice and I haven't been once. Feb 16 21:31:09 <[g2]> night Feb 16 21:31:23 <[g2]> he probably weighs more :) Feb 16 21:31:33 [g2]: It'll be tomorrow before you can test the verify code. Feb 16 21:31:38 <[g2]> or gets more exercise on the Tropical local Feb 16 21:31:43 Perhaps. Feb 16 21:31:47 I'm not so big. Feb 16 21:32:01 <[g2]> You're a GIANT in the channel :) Feb 16 21:32:12 Big personality. Feb 16 21:32:18 Compensation behavior Feb 16 21:33:05 <[g2]> I'll look for a .27 version and help the compare/copy commands Feb 16 21:33:14 K. Feb 16 21:33:27 You heading out? Feb 16 21:33:36 <[g2]> nod. Feb 16 21:33:40 nite Feb 16 21:34:04 <[g2]> cheers Feb 16 21:39:02 That was actually my Blinner. Feb 16 21:39:32 Second breakfast? Feb 16 21:39:48 "breakfast" was 3 cups of coffee. Feb 16 21:39:54 Ouch. Feb 16 21:39:59 Lunch.. I kind of forgot about. Feb 16 21:40:19 so its really Blinner. ;-) Feb 16 21:40:38 I'm gonna do something for you guys. I'm gonna move the default environment into the first block so you can set it. Feb 16 21:41:35 That should make things easier. Feb 16 21:58:46 dyoung: nite. **** ENDING LOGGING AT Wed Feb 16 23:59:56 2005