**** BEGIN LOGGING AT Mon Aug 01 23:59:56 2005
Aug 02 02:57:09 <rwhitby-away> guys, let's continue landslide's 128MB apex discussion here ...
Aug 02 02:57:36 <rwhitby-away> [19:07] landslide: u know how i have a 128mb slug (4 x 256mbit).
Aug 02 02:57:36 <rwhitby-away> [19:08] landslide: i set the bank size to 0x04000000 and enabled the second bank
Aug 02 02:57:36 <rwhitby-away> [19:08] landslide: then compiled
Aug 02 02:57:36 <rwhitby-away> [19:08] landslide: when i do version i get this
Aug 02 02:57:37 <rwhitby-away> [19:08] landslide:   memory:
Aug 02 02:57:37 <rwhitby-away> [19:08] landslide:           0x0 0x02000000 (32 MiB)
Aug 02 02:57:38 <rwhitby-away> [19:08] landslide:           0x4000000 0x02000000 (32 MiB)
Aug 02 02:57:40 <rwhitby-away> [19:08] landslide:   nor:    8MiB total  32B write buffer
Aug 02 02:57:42 <rwhitby-away> [19:08] landslide:           region 0:  64 blocks of 131072 (0x20000) bytes
Aug 02 02:57:44 <rwhitby-away> [19:08] landslide:   cpu: id 0x690541f1  ctrl 0xafa  cpsr 0x200000d3
Aug 02 02:57:46 <rwhitby-away> [19:09] landslide: it still thinks they are 32MiB yet the second bank starts at 64MiB.
Aug 02 02:57:48 <rwhitby-away> [19:09] landslide: i'm going to trace through the code and work out what's going on.
Aug 02 02:57:52 <rwhitby-away> (for beewoolie to see in the logs)
Aug 02 03:02:38 <dyoung> #openjtag. the place where all the funky hardware developments happen.
Aug 02 03:03:00 <rwhitby-away> heh, thx
Aug 02 03:08:55 <landslide> ok here..
Aug 02 03:09:30 <landslide> i'm just debugging the drv-mem.c memory_scan() function.
Aug 02 03:09:50 <landslide> where it does a mark and identify and counts the blocks.
Aug 02 03:09:57 <landslide> i'm trying to work out what it does.
Aug 02 03:10:05 <landslide> keep in mind I might have faulty ram chips...
Aug 02 03:10:31 <landslide> they were removed from another board so got 2 doses of heat from the rework station
Aug 02 03:28:57 <landslide> i think i need to load it into flash
Aug 02 03:29:35 <landslide> some of that drv-mem.c code uses the APEX_VMA_START/END which i don't understand why.
Aug 02 04:12:54 <landslide> how many regions is memoryscan() supposed to find? I think there is a bug in the identify portion, it seems that once it gets past 0x2000000 it keeps finding the region end.. should there be only 1 region found?
Aug 02 04:13:20 <landslide> or is this relying on some quirk or trick to find out how many ram chips there are?
Aug 02 04:14:04 <landslide> see i printed out the pointer and data and the data and pointer are the same until the second block of 16 mb.
Aug 02 04:15:27 <landslide> the data is then 0x02000000 less than the pointer.
Aug 02 04:16:33 <landslide> pointer = pl ... data = *pl
Aug 02 05:38:26 <landslide> i'
Aug 02 05:38:32 <landslide> i've had some success..
Aug 02 05:38:41 <DaKa2> :)
Aug 02 05:40:08 <landslide> i found out that if i did printf("SDR_CONFIG %lX", (unsigned long)SDR_CONFIG); from drv_mem.c  in function memory_init()
Aug 02 05:40:19 <landslide> it returned 0x18, which is wrong..
Aug 02 05:40:45 <landslide> i had forced it to SDR_CONFIG = SDR_CONFIG_CAS3 | 0x03;  in initialize.c
Aug 02 05:40:53 <landslide> for some reason it gets reset.
Aug 02 05:41:18 <landslide> anyway i forced it again in memory_init() and all the memory is now available.
Aug 02 05:41:26 <landslide> the memory_scan() function worked fine.
Aug 02 05:41:34 <landslide> for both banks.
Aug 02 05:42:16 <landslide> so anyway after reading SDR_CONFIG once i forced it in memory_init() it was 0x1B which is correct for my configuration (4x16Mx16)
Aug 02 05:44:48 <landslide> now i get this: ->
Aug 02 05:44:56 <landslide>   apex => mem:0x00200000+0xe488   (58504 bytes)
Aug 02 05:44:56 <landslide>   env  => nor:128k+64k
Aug 02 05:44:56 <landslide> Services:
Aug 02 05:44:57 <landslide>   memory:
Aug 02 05:44:57 <landslide>           0x00000000 0x08000000 (128 MiB)
Aug 02 05:44:58 <landslide>   nor:    8MiB total  32B write buffer
Aug 02 05:44:59 <landslide>           region 0:  64 blocks of 131072 (0x20000) bytes
Aug 02 05:45:01 <landslide>   cpu: id 0x690541f1  ctrl 0xafa  cpsr 0x200000d3
Aug 02 05:49:10 <landslide> the ram is working fine, i've done numerous fills and dump checks in each bank.
Aug 02 06:19:54 <rwhitby> so does it work?
Aug 02 06:32:40 <landslide> very close.
Aug 02 06:32:46 <landslide> i can't get the kernel to boot.
Aug 02 06:32:55 <landslide> mind you, i'm running apex from ram.
Aug 02 06:33:57 <landslide> even when i revert to the same configuration as the wiki the kernel will uncompress then say 'crc checksum error'
Aug 02 11:03:04 <beewoolie-afk> prpplague: Hey.  I just missed your ping yesterday.
Aug 02 11:03:06 <beewoolie-afk> dyoung: hey man
Aug 02 11:03:47 <prpplague> beewoolie-afk: hey, just saying hello
Aug 02 11:03:51 <prpplague> beewoolie-afk: nothing major
Aug 02 11:04:11 <beewoolie-afk> prpplague: FYI.  The ethernet driver and IP stack for APEX are released.
Aug 02 11:04:15 <beewoolie-afk> It's kinda handy.
Aug 02 11:04:30 <beewoolie-afk> what ethernet controller are you guys using?
Aug 02 11:05:53 <prpplague> cs8900 8-bit polled, i.e. the packet-wacker
Aug 02 11:06:36 <beewoolie-afk> Hmm.  I thought as much.
Aug 02 11:06:49 <beewoolie-afk> I've got one on one of the KEV boards, so maybe I'll write the driver for that one, too.
Aug 02 11:07:01 <beewoolie-afk> It isn't much work since APEX is so simple.
Aug 02 11:07:10 <prpplague> beewoolie-afk: simple for you, hehe
Aug 02 11:07:14 <prpplague> beewoolie-afk: you wrote it
Aug 02 11:07:51 <beewoolie-afk> Perhaps.  The interface for the ethernet drivers is pretty much three calls.  init, read, write.
Aug 02 11:08:13 <prpplague> beewoolie-afk: lovely
Aug 02 11:08:21 <prpplague> beewoolie-afk: i'll have another look
Aug 02 11:08:32 <beewoolie-afk> v1.3.0
Aug 02 11:09:25 <beewoolie-afk> dyoung: Are you listening?  If we have the IAL linked into APEX we could use the TFTP code on the slug.  Hint hint.
Aug 02 11:20:02 <prpplague> beewoolie-afk: why not use the tftp code from rmk?
Aug 02 13:20:24 <beewoolie-afk> prpplague: what code from RMK?  The tftp code isn't really the hard part.  In fact, the code isn't very interesting no matter how it is done.  The tricky part is integrating the protocol into the loader.
Aug 02 13:21:20 <prpplague> beewoolie-afk: rmk release a bootloader tftp code awhile back
Aug 02 13:21:30 <prpplague> beewoolie-afk: let me look to see if i have a copy handy
Aug 02 13:21:41 <beewoolie-afk> KO.  It's kinda too late since it's already written.
Aug 02 13:21:57 <beewoolie-afk> What we need is the IAL so that we can driver the MAC from APEX.
Aug 02 13:22:31 <beewoolie-afk> prpplague: I'd be interested, tho, because I haven't added bootp or dhcp.
Aug 02 13:24:43 <prpplague> beewoolie-afk: i can't seem to access our cvs server at the momment
Aug 02 13:24:50 <prpplague> beewoolie-afk: i'll pull it down shortly
Aug 02 13:24:55 <beewoolie-afk> thx
Aug 02 13:28:45 <rwhitby-asleep> beewoolie-afk: did you see landslide-zzzz's comments here earlier?
Aug 02 13:29:10 <beewoolie-afk> rwhitby-asleep: Didn't.  Scrolling...
Aug 02 13:29:23 <beewoolie-afk> Looks like it was before I was on.  Was it on this channel?
Aug 02 13:29:30 <rwhitby-asleep> yep
Aug 02 13:29:45 <beewoolie-afk> Wanna give me the reader's digest version?
Aug 02 13:29:55 <rwhitby-asleep> he's got a 128MB slug and was getting apex to run on it
Aug 02 13:30:04 <beewoolie-afk> Successfully?
Aug 02 13:31:48 <rwhitby-asleep> http://pastebin.ca/19125
Aug 02 13:31:55 <beewoolie-afk> thx
Aug 02 13:34:40 <beewoolie-afk> Ah.  One of the things that he didn't understand is that the SDRAM is *not* configured when APEX runs from ram.  It should be obvious, but most people haven't thought it through.
Aug 02 13:35:34 <beewoolie-afk> There is no way to know what should happen if we reconfigure the SDRAM controller when the running code out of RAM.
Aug 02 13:35:56 <beewoolie-afk> In other words, the SDRAM mode isn't being reset in APEX.  It's never being set.
Aug 02 13:36:51 <beewoolie-afk> You can also tell him that if he's having problems with the kernel decompressing, it is a good idea to checksum the uploaded file before asking the kernel to decompress.
Aug 02 13:37:41 <rwhitby-asleep> http://pastebin.ca/19126 <- some stuff at the start of this before the previous one, and a bit in the middle and end
Aug 02 13:37:46 <beewoolie-afk> I suspect the problem is that the SDRAM isn't properly configured 
Aug 02 13:38:32 <prpplague> beewoolie-afk: hey, you know a good tool to convert arm asm into some psuedo code for readability?
Aug 02 13:38:43 <rwhitby-asleep> beewoolie-afk: he's in AU timezone, like me (but I'm up early)
Aug 02 13:38:46 <beewoolie-afk> ndisasm.  Look at my wiki.
Aug 02 13:39:09 <beewoolie-afk> prpplague: I linked the disasm there some time ago.  wiki.buici.com
Aug 02 13:39:52 <beewoolie-afk> rwhitby-asleep: Fair enough.  I'm reviewing the SDRAM init code just to see if there is something I can see.  Perhaps I should add a message at signon about the SDRAM *not* being initialized.
Aug 02 13:40:16 <rwhitby-asleep> beewoolie-afk: the OE compiler vs crosstool is intriging too (from the second pastebin)
Aug 02 13:40:31 <beewoolie-afk> I haven't gotten all the way through yet.
Aug 02 13:41:03 <prpplague> beewoolie-afk: cool thanks
Aug 02 13:42:40 <rwhitby-asleep> beewoolie-afk: I put apex into OpenEmbedded as a .bb file, but didn't test it.  When we buld using OE, it seems to produce a binary which gives GDB codes on the serial console.  Nobody knows why.
Aug 02 13:42:42 <beewoolie-afk> rwhitby-asleep: The compiler stuff is odd.  As I've never seen any such failures, it's hard to imagine why.  I suspect that either a) they aren't using a big-endian compiler or b) there is something wrong with their config.
Aug 02 13:42:59 <beewoolie-afk> rwhitby-asleep: That isn't what you think it is.
Aug 02 13:43:07 <beewoolie-afk> The gdb codes come from redboot.
Aug 02 13:43:23 <rwhitby-asleep> ah
Aug 02 13:43:27 <prpplague> beewoolie-afk: hmm, that doesn't appear to provide anything more than just objdump
Aug 02 13:43:30 <beewoolie-afk> Apex has no GDB code at all.  It means that you are runnning APEX from RAM and it's crashing.
Aug 02 13:43:40 <beewoolie-afk> prpplague: What are you looking for?
Aug 02 13:43:44 <beewoolie-afk> C code?
Aug 02 13:44:09 <prpplague> beewoolie-afk: not nessarly c, but something psuedo like that easier to read
Aug 02 13:44:32 <beewoolie-afk> rwhitby-asleep: If you send me one of these errant versions of APEX, I'll see if I can see what is the matter.
Aug 02 13:44:42 <prpplague> i guess i'm slow with asm, takes me forever to step through the asm and write down what its doing
Aug 02 13:44:49 <beewoolie-afk> rwhitby-asleep: It's important to set the MMU disable option in APEX so that it gets access to the whole address space.
Aug 02 13:44:57 <beewoolie-afk> prpplague: Not sure what else there is.
Aug 02 13:45:24 <rwhitby-asleep> beewoolie-afk: I'll get dyoung to send you a failing binary
Aug 02 13:45:29 <beewoolie-afk> K.
Aug 02 13:45:56 <rwhitby-asleep> I haven't run Apex myself yet (lack of time), so I'm only relaying messages at the moment :-)
Aug 02 13:46:39 <rwhitby-asleep> but I'm keen to get it into our standard builds, as we need it for DebianSlug
Aug 02 13:47:19 <beewoolie-afk> rwhitby-asleep: I'll take a look as soon as I get a binary.  The elf file is the most useful.
Aug 02 13:48:16 <beewoolie-afk> rwhitby-asleep: BTW, there may be an error in the code.
Aug 02 13:48:59 <beewoolie-afk> It looks like I'm assuming that the CPU clock is 133MHz.  At least, that's the fundamental frequency for the SDRAM refresh clock. I need to make sure that a deunderclocked slug has the right refresh clock.
Aug 02 13:49:45 <rwhitby-asleep> beewoolie-afk: I might be able to build a binary for you now to look at
Aug 02 13:49:51 <beewoolie-afk> k.
Aug 02 13:50:12 <rwhitby-asleep> can you /msg me an email address to send it to?
Aug 02 13:54:44 <rwhitby-asleep> beewoolie-afk: just the apex.bin file?
Aug 02 13:54:51 <beewoolie-afk> The apex file is better.
Aug 02 13:55:20 <beewoolie-afk> I added some code to the ixp init that will exclaim that SDRAM has not been initialized if it runs from SDRAM.
Aug 02 13:57:50 <rwhitby-asleep> beewoolie-afk: sent - I haven't tried this one, so I dunno if it works or not.
Aug 02 13:58:19 <beewoolie-afk> I assume you're building it with the OE compiler.
Aug 02 13:58:24 <rwhitby-asleep> yep
Aug 02 13:58:36 <rwhitby-asleep> that's the automatically built one (bb apex)
Aug 02 13:58:42 <rwhitby-asleep> (bitbake apex that is)
Aug 02 14:05:50 <beewoolie-afk> rwhitby-asleep: would you mind sending the .config file?
Aug 02 14:08:09 <rwhitby-asleep> sent
Aug 02 14:08:51 <beewoolie-afk> rwhitby: It looks like the optimization level is different.
Aug 02 14:08:55 <beewoolie-afk> What compiler are you using/
Aug 02 14:08:58 <beewoolie-afk>  ?
Aug 02 14:09:57 <rwhitby> gcc 3.4.4
Aug 02 14:10:06 <beewoolie-afk> You've also set a ramdisk.  Is this for unslung?  We don't need a ramdisk for openslug.
Aug 02 14:10:36 <rwhitby> this is just for general nslu2 - we haven't sorted out the right config yet
Aug 02 14:10:49 <beewoolie-afk> Shouldn't matter.
Aug 02 14:10:49 <rwhitby> just trying to get to the apex console at this stage
Aug 02 14:11:26 <beewoolie-afk> Let me see about the compiler version.  It's possible that there is some sort of new bug in the compiler.
Aug 02 14:11:32 <beewoolie-afk> I'm using 3.4.2
Aug 02 14:12:29 <beewoolie-afk> I'll have to build a new compiler to test this.  
Aug 02 14:12:40 <beewoolie-afk> You know what that means.
Aug 02 14:12:57 <rwhitby> I can tar up the cross directory and send it to you if you like
Aug 02 14:13:30 <beewoolie-afk> I'd rather build one just so I can track the pedigree.
Aug 02 14:13:34 <rwhitby> ok
Aug 02 14:13:53 <beewoolie-afk> Besides, I'm going to test with the LH processors first and those are LE.
Aug 02 14:14:10 <rwhitby> ok
Aug 02 14:14:14 <beewoolie-afk> Thanks for the help.
Aug 02 14:14:28 <rwhitby> I'll also send you the run.do_compile script which OE uses to compile it
Aug 02 14:16:20 <rwhitby> sent.  Thank *you* :-)
Aug 02 14:20:18 <beewoolie-afk> Alright.
Aug 02 14:21:21 <rwhitby> anything else that can help?
Aug 02 14:26:48 <beewoolie-afk> I'll let you know.  It'll be later today when I can look at this again.
Aug 02 14:27:00 <beewoolie-afk> Trying to get an audio codec working ATM.
Aug 02 14:27:44 <landslide-zzzz> just heading into work.. i scrolled back, and understand the problem now.. :)
Aug 02 14:27:54 <landslide-zzzz> i'll have a look at it when i return home tonight.
Aug 02 14:27:55 <beewoolie-afk> landslide-zzzz: hey man
Aug 02 14:28:03 <landslide-zzzz> thanks beewoolie... :)
Aug 02 14:28:09 <beewoolie-afk> cheers
Aug 02 14:28:26 <beewoolie-afk> rwhitby: BTW, does the BB reference the openslug_config?
Aug 02 14:28:42 <beewoolie-afk> It should do something like this:  make openslug_config
Aug 02 14:28:48 <beewoolie-afk> when it is doing the setup.
Aug 02 14:32:38 <beewoolie-afk> landslide-zzzz: Do you get the chip config now?  the 4x16Mx16 is 4 banks, 16M per bank, 16 bit access per chip
Aug 02 14:33:22 <prpplague> beewoolie-afk: what does a "bx r0" do when r0=0x590000 ?
Aug 02 14:34:26 <beewoolie-afk> I thought that the BX instruction was for switching to thumb mode.
Aug 02 14:34:43 <prpplague> thats what i read as well
Aug 02 14:35:04 <beewoolie-afk> Says, tho, that when the low bit is 0, it is *not* a thumb branch.
Aug 02 14:35:20 <beewoolie-afk> That's a simple jump, but I couldn't tell you why it is being used.
Aug 02 14:35:58 <prpplague> ok so if its not in thumb its going to do a simple jump to 0x590000 ?
Aug 02 14:36:10 <beewoolie-afk> That's what I'd guess.
Aug 02 14:36:13 <beewoolie-afk> It's an odd address.
Aug 02 14:36:19 <beewoolie-afk> Odd as in wierd.
Aug 02 14:36:40 <prpplague> beewoolie-afk: hehe yea they did alot of weird stuff on the juicebox
Aug 02 14:36:57 <beewoolie-afk> Hm..  Back to the juicer.
Aug 02 14:37:06 <beewoolie-afk> Juiceroni
Aug 02 14:37:11 <beewoolie-afk> the jucierator
Aug 02 14:37:17 <prpplague> yea, trying to take short break
Aug 02 14:37:34 <prpplague> beewoolie-afk: i've got so much work to do, and i'm about a week behind schedule
Aug 02 14:37:45 <prpplague> beewoolie-afk: and to add to it, i'm totally unmotivated today
Aug 02 14:37:58 <beewoolie-afk> NAP TIME!
Aug 02 14:40:13 <landslide-zzzz> beewollie: does that mean i can't access it?
Aug 02 14:40:30 <landslide-zzzz> i configured the SDR_CONFIG register (memory selection) to 0x03.
Aug 02 14:40:37 <landslide-zzzz> along with the CAS3 bit.
Aug 02 14:45:01 <landslide-zzzz> l8r
Aug 02 15:57:24 <landslide> beewoolie: what were you saying about the memory configuration?
Aug 02 15:57:42 <landslide> is my 4x16M16 not going to work because of the 'word size'?
Aug 02 17:41:40 <beewoolie-afk> landslide: Hey.  I've been all over the place today.  You still listening?
Aug 02 18:06:19 <landslide> haha yeah
Aug 02 18:06:27 <landslide> i'm around.. at work at the moment but can chat.
Aug 02 18:18:41 <beewoolie> Sorry.  I only get a ping when my name is in the text.
Aug 02 18:18:51 <beewoolie> Do you understand the memory config stuff yet?
Aug 02 18:19:15 <beewoolie> It can be confusing when running from SDRAM and you expect that SDRAM is going to be reconfigured.
Aug 02 18:19:23 <beewoolie> landslide: beep
Aug 02 18:37:52 <beewoolie> landslide: ttfn
Aug 02 18:48:57 <landslide> sorry ;)
Aug 02 18:49:21 <landslide> beewoolie: what i'll do tonight it load apex into flash...
Aug 02 18:49:35 <landslide> do I use xmodem for the 'xreceive' command? or xmodem-1k
Aug 02 18:50:04 <landslide> beewoolie: another thing is I remember reading you said network support is working now? is that true for the nslu2?
Aug 02 18:50:12 <landslide> so i can tftp?
**** ENDING LOGGING AT Tue Aug 02 23:59:56 2005