| 00:20.46 | beewoolie-afk | landslide-wk: Hey, I'm back. |
| 00:37.41 | *** join/#openjtag jamie (~jamie@jamie.active.supporter.pdpc) |
| 00:37.45 | *** join/#openjtag jamie___ (~jamie@jamie.active.supporter.pdpc) |
| 01:01.11 | *** join/#openjtag malfi (~malte@dsl-082-082-197-240.arcor-ip.net) |
| 01:05.33 | *** join/#openjtag ka6sox-away (~tking@adsl-66-159-198-116.dslextreme.com) |
| 01:47.56 | landslide-wk | hey beewoolie |
| 01:49.55 | beewoolie-afk | Hey man. |
| 01:50.03 | beewoolie-afk | landslide-wk: erm, hey |
| 01:50.13 | beewoolie-afk | Somethings wrong since I'm not being ping'd/ |
| 01:50.18 | *** join/#openjtag ByronT (~byron-por@ByronT.nslu2-linux) |
| 01:52.00 | beewoolie-afk | tee hee |
| 01:52.01 | ka6sox-away | beewoolie-afk, consider yourself pinged... ;) |
| 01:52.04 | beewoolie-afk | That tickles. |
| 01:52.47 | beewoolie-afk | landslide-wk: Do you have any Q's about getting your fatslug booting properly? |
| 02:43.23 | landslide-wk | beewoolie: sorry, on another machine... ok i managed to get the fatslug to boot.. but not like the documentation says |
| 02:43.55 | landslide-wk | what i did was move the entire 0x50060000 into 0x01000000 and then types go 0x01000000 |
| 02:43.59 | landslide-wk | it booted into linux then. |
| 02:44.12 | landslide-wk | if I try and boot with the startup... it fails when decompressing the kernel. |
| 02:44.39 | landslide-wk | i remember you said there was some clock issues in apex... my slug is 266Mhz so that might be related? |
| 02:48.41 | landslide-wk | i also tried the copy commands which are on the apex wiki... there were 2 copy nor: commands instead of the default startup.. it did change in that it got to 'done decompressing the kernel' however the kernel did not boot. |
| 02:48.50 | landslide-wk | i pasted the configuration in irc from home last night. |
| 02:49.09 | landslide-wk | what is the url for the log? i'll find what i wrote. |
| 03:05.14 | beewoolie | landslide-wk: First of all. I've got an de-underclocked slug and it boots fine with APEX. |
| 03:05.59 | beewoolie | landslide-wk: You also should understand that APEX isn't going to reinitialize SDRAM since you're running from SDRAM. |
| 03:06.47 | beewoolie | landslide-wk: I wonder if you can boot OK with an APEX that only thinks there's 32MB of SDRAM. In that case, both redboot and apex should see the same version of memory. |
| 03:07.52 | beewoolie | landslide-wk: I looked at the SDRAM init and I don't think that there is anything different for 128MB other than the organization of the rows and colums of SDRAM. |
| 03:08.22 | beewoolie | Still, there isn't much I can do about making sure that the SDRAM init is correct if you don't run from FLASH. |
| 03:08.34 | beewoolie | landslide-wk: If you are feeling gutsy, there is one thing you can try. |
| 03:08.46 | beewoolie | You can write APEX into flash at a place different from redboot. |
| 03:09.17 | beewoolie | Then, when you jump to it, APEX will perform a complete initialization of the system. |
| 03:10.37 | beewoolie | landslide-wk: BTW, when your message includes my handle, I'll get a beep so I know someone is trying to contact me. |
| 03:11.02 | beewoolie | If my handle is beewoolie-afk and you put beewoolie in the message I won't get the beep |
| 03:27.00 | beewoolie | landslide-wk: BTW, it isn't clear from your description what you are doing. Are you jumping to the kernel? or are you using the boot command? There is an important difference. The boot command configures the atags array which passes the memory map to the kernel. |
| 03:36.06 | *** join/#openjtag ka6sox (~ka6sox@adsl-66-159-198-116.dslextreme.com) |
| 04:06.08 | *** part/#openjtag malfi (~malte@dsl-082-082-197-240.arcor-ip.net) |
| 05:17.39 | Jacmet | beewoolie: Did you ever look into why the Sercomm-provided RedBoot doesn't seem to setup the ATAGs array? |
| 05:50.30 | landslide-wk | beewollie: it's actually running from flash right now. |
| 05:50.34 | landslide-wk | i replaced redboot already. |
| 05:51.36 | landslide-wk | beewoolie: i can get the kernel to execute by using the 'go' command after moving the kernel from flash into 0x01000000. |
| 05:52.01 | landslide-wk | beewoolie: if I use the boot command it will not execute. it crashes either while uncompressing the kernel or immediately after. |
| 05:53.00 | landslide-wk | so i'm effectively booting linux with no ATAG's with the kernel running completely in SDRAM. |
| 06:00.54 | *** join/#openjtag ByronT (~byron-por@ByronT.nslu2-linux) |
| 06:18.37 | beewoolie | Jacmet: I don't think I understand your question. Redboot doesn't setup atags because...it doesn't. The folks who ported the kernel back then weren't very keen on adhering to convention. |
| 06:19.15 | beewoolie | landslide-wk: Can you show me the output from APEX after it starts? |
| 06:19.32 | beewoolie | landslide-wk: The best way would be to send it in email. |
| 06:20.20 | landslide-wk | ok what's your e-mail i'll send it when i get home. |
| 06:20.29 | landslide-wk | it's calling the startup script. |
| 06:20.33 | beewoolie | landslide-wk: Also, it is important that you run the kernel from SDRAM. You *can* execute the kernel directly from flash, but it requires a custom setup. The kernel decompressor assumes that there is RAM available after the compressed kernel image. |
| 06:20.38 | landslide-wk | if that is what you are wondering. |
| 06:21.13 | beewoolie | landslide-wk: There are a couple of other things to look at. |
| 06:21.36 | landslide-wk | ok. |
| 06:21.42 | beewoolie | For example, is the version in SDRAM the same as the version in flash? The checksum command is handy for that. |
| 06:21.50 | landslide-wk | i'll check that. |
| 06:22.13 | beewoolie | There is nothing magic about addres 0x01000000 except that that is a place in SDRAM that redboot permits us to use. |
| 06:22.35 | beewoolie | it would be helpful to see the startup log as well as the output of the version command. |
| 06:22.35 | landslide-wk | is there a log of the irc ? |
| 06:22.44 | beewoolie | I don't know. |
| 06:22.46 | landslide-wk | i pasted it last night. |
| 06:22.48 | beewoolie | I'm a primitive users |
| 06:23.04 | beewoolie | You can use pastebin, too. |
| 06:23.07 | landslide-wk | hehe. from old irc2 days. |
| 06:23.11 | beewoolie | pastebin.ca |
| 06:23.17 | landslide-wk | ok. |
| 06:23.41 | landslide-wk | i'll have a look tonight. what time to you usually get on/ |
| 06:23.45 | landslide-wk | i'll be home in 2 hours. |
| 06:23.50 | landslide-wk | it must be early morn for you? |
| 06:24.50 | beewoolie | 11pm |
| 06:25.07 | beewoolie | You have a 2hr commute? |
| 06:25.11 | ka6sox | he's a littl behind me.... |
| 06:25.24 | ka6sox | like 26 minutes |
| 06:25.45 | landslide-wk | 1 hr usually and that's driving |
| 06:25.46 | ka6sox | strange since I'm west of him. |
| 06:25.50 | landslide-wk | sydney traffic is pathetic. |
| 06:25.51 | beewoolie | And you thought that Cali was laid back. |
| 06:26.17 | ka6sox | beewoolie, it is...but I live in the pacific...not on NOrth America. |
| 06:26.30 | landslide-wk | i'll e-mail you the details when i get home. |
| 06:26.36 | beewoolie | landslide-wk: k |
| 06:26.53 | beewoolie | ka6sox: I thought you lived near LA. Did your house float into the ocean? |
| 06:26.58 | landslide-wk | so you actually wrote apex from the ground up? |
| 06:27.03 | landslide-wk | man that is impressive. |
| 06:28.05 | beewoolie | landslide-wk: an act of desperation. |
| 06:28.20 | ka6sox | beewoolie, I live 100miles west of LA |
| 06:28.35 | beewoolie | I think that the only piece I didn't write is the xmodem receiver. I have my own code, but it's larger because it handles traffic in both directions. |
| 06:28.53 | landslide-wk | hehe. awesome. |
| 06:28.57 | beewoolie | ka6sox: that would be west of catalina, no? |
| 06:29.04 | ka6sox | yes |
| 06:29.13 | landslide-wk | i remember you saying the networking is working. is that for the slug or another device? |
| 06:29.17 | ka6sox | catalina is southeast of me. |
| 06:29.33 | beewoolie | Not the farallons... |
| 06:32.24 | ka6sox | farallons are north. |
| 06:32.25 | beewoolie | ka6sox: Channel islands? |
| 06:32.35 | ka6sox | yes..near the Channel Islands. |
| 06:32.44 | ka6sox | Santa Cruz is due south |
| 06:33.10 | ka6sox | San Miguel is southwest and Anacapa is south east |
| 06:34.08 | beewoolie | ka6sox: It's not on the google map I'm looking at. |
| 06:34.20 | beewoolie | It's a little scarce on place names. |
| 06:35.17 | beewoolie | landslide-wk: I have a stack and a couple of drivers. The NPE is a problem because it requires the very-difficult-intel-access-library. |
| 06:35.17 | ka6sox | Santa Barbara |
| 06:35.48 | beewoolie | ka6sox: Right. I thought you were saying that you lives 100miles due west. |
| 06:38.19 | ka6sox | downtown LA to SBA is within 1 degree of due west |
| 06:38.58 | ka6sox | at least that is what my GPS tells me. |
| 06:39.19 | beewoolie | That one degree makes a difference when I'm on the ground. |
| 06:39.34 | ka6sox | oooh yeah |
| 06:39.43 | ka6sox | you could be swimming |
| 06:40.10 | ka6sox | one day I was down at the harbor when they brought it a 25' Great White. |
| 06:40.32 | beewoolie | Brought it in dead? And did what with it? |
| 06:41.06 | ka6sox | it got caught up and it was dead... |
| 06:41.18 | ka6sox | dunno where it went...maybe to the taxidermist |
| 06:41.45 | ka6sox | I *think* that it is hanging in the Natural History museum on the pier. |
| 06:43.36 | beewoolie | google maps make it easy to see the clear-cuts in the forest. |
| 06:46.41 | ka6sox | depends on when they were taken. |
| 06:49.03 | beewoolie | To be sure, the maps are old. Still, there are loads of them on the olympic peninsula. |
| 06:49.33 | beewoolie | http://maps.google.com/maps?ll=48.198591,-124.415359&spn=0.250445,0.601433&t=h&hl=en |
| 06:50.45 | ka6sox | with as much rain as that place gets it should grow back toon. |
| 06:50.47 | ka6sox | er soon. |
| 06:50.50 | *** join/#openjtag ep1220 (~NN@gate.epatec.at) |
| 06:51.15 | beewoolie | Well, yeah. Trees are weeds in this part of the country. it's the wildlife that suffers most. |
| 06:52.16 | ka6sox | I hear your parties up there get pretty wild. |
| 06:52.43 | beewoolie | Yeah. Naked fire dancing. |
| 06:52.52 | beewoolie | Hot naked fire dancing. |
| 06:54.03 | beewoolie | nitey nite |
| 06:54.36 | ka6sox | nitey nite... |
| 06:55.37 | Jacmet | beewoolie: It doesn't? Current CVS does atleast - I don't know about the sercomm version |
| 06:56.26 | beewoolie | Jacmet: Lots of the early arm ports were sloppy. I think that the ixp port hard coded all of the parameters in the kernel instead of depending on the boot loader. |
| 06:58.33 | Jacmet | beewoolie: As far as I can see it's done correctly in packages/hal/arm/arch/current/src/redboot_linux_exec.c |
| 06:59.03 | Jacmet | beewoolie: and the BOOT_PARAMS correctly looks at 0x100 - but there's just garbage there :/ |
| 06:59.06 | beewoolie | Is that the version of the code that shipped on the slug? |
| 07:01.58 | Jacmet | beewoolie: No, that's latest cvs - but as far as I can see the sercomm version is the same (minus the endianswap feature now in cvs) |
| 07:02.22 | beewoolie | How do you mean? Have you checked the source? |
| 07:02.57 | Jacmet | beewoolie: I know you're probably not interested, but it would be nice to get RedBoot a bit more functional (E.G. setting cmdline) for people who don't dare installing apex ;) |
| 07:03.21 | beewoolie | You're right. I'm less than interested. |
| 07:03.26 | Jacmet | beewoolie: yes, I checked the nslu2 sources from linksys - presumably that's what is in there |
| 07:03.41 | Jacmet | beewoolie ;) |
| 07:03.55 | beewoolie | It is possible that the nslu2 version doesn't use that code. |
| 07:04.02 | beewoolie | That's part of the reason that I don't like redboot. |
| 07:04.09 | beewoolie | It's really hard to tell what code is being executed. |
| 07:04.23 | Jacmet | beewoolie: what was actually your motivation for writing yet another bootloader? |
| 07:04.31 | beewoolie | The use so many macros that it requires a complete understanding of the code in order to modify it. |
| 07:04.42 | beewoolie | since you asked, no |
| 07:04.59 | beewoolie | I write APEX because blob suffers from some of the same problems. |
| 07:05.15 | beewoolie | On my targets, the Sharp LH processors, I had a choice between blob and uboot. |
| 07:05.34 | Jacmet | beewoolie: yes, it takes a bit of getting used to - but once you know it I actually think it's really nicely structured - you have generic->arch->variant->platform and you can always override if the layer above you doesn't fit you |
| 07:05.36 | beewoolie | Both are quite awful because of how difficult they are to configure. |
| 07:05.51 | beewoolie | I call that overdesign. |
| 07:06.13 | beewoolie | It doesn't cope with the sorts of things that I care about. |
| 07:06.25 | beewoolie | I want to be able to add and remove features quickly and reliably. |
| 07:06.26 | Jacmet | well, uboot isn't called the universal bootloader for nothing ;) |
| 07:06.44 | beewoolie | Uh huh. I've had plenty of experience with it and the author. |
| 07:06.53 | beewoolie | It has some of the most irritating features. |
| 07:07.04 | beewoolie | For example, it requires that all kernel images be prefixed with a header. |
| 07:07.07 | beewoolie | Blech. |
| 07:07.16 | Jacmet | beewoolie: come on, it's always fun to read wdenx's postings ;) |
| 07:08.08 | Jacmet | beewoolie: well, that's just to keep metadata - I find it kinda neat - it's kinda similar to the FIS in redboot |
| 07:08.09 | beewoolie | I don't have much of a sense of humor about it. I wasted several weeks worth of good effort. Denk wouldn't merge it and would only throw tantrums because some of my lines had whitespace at the end. |
| 07:08.29 | beewoolie | That is a perfect example of an overgeneralization. |
| 07:08.49 | beewoolie | A small group of users who like and need the feature are inconvenienced by it. |
| 07:09.20 | Jacmet | true - he's hard, but I guess he needs to be to keep it from getting messy |
| 07:09.31 | beewoolie | A better solution, IMHO, would be to append an executable header that could store the metadata, but wouldn't change the usability of the file. |
| 07:09.40 | beewoolie | There is no reason for his tantrum. |
| 07:09.50 | beewoolie | A simple script to strip the whitespace would have sufficed. |
| 07:09.57 | beewoolie | Moreover, it is a trite complaint. |
| 07:10.17 | beewoolie | APEX uses the kernel build system and it's configurator. |
| 07:10.24 | beewoolie | Much much easier to work with. |
| 07:10.31 | Jacmet | beewoolie: I don't see much difference between having the metadata before or after the image |
| 07:10.33 | beewoolie | And, the build process is nearly optimal. |
| 07:10.45 | beewoolie | Append doesn't mean 'after'. |
| 07:11.12 | Jacmet | what do you mean then? |
| 07:11.14 | beewoolie | The metadata could be a prefix on the file with a jump instruction to the real first intruction of the file. |
| 07:12.00 | beewoolie | append: To fix to; attach: append a charm to the bracelet. |
| 07:12.27 | Jacmet | beewoolie: yes it could, but as the uImage header is always 64bytes you could just execute from there |
| 07:12.28 | beewoolie | A magic number in the file would let the metadata be recognizable. |
| 07:12.38 | beewoolie | You miss the point. |
| 07:12.52 | beewoolie | Kernel images are used in a uniform manner in every other situation. |
| 07:13.12 | beewoolie | uImages are the *only* ones that don't execute from the first instruction. |
| 07:13.23 | beewoolie | First word, that is. |
| 07:13.51 | beewoolie | I cannot count the number of times I've seen messages on the list about the inability of users to boot Linux from uboot because of this. |
| 07:14.27 | Jacmet | beewoolie: well, you cannot blaim uboot for the fact that users don't rtfm ;) |
| 07:14.42 | beewoolie | it's like the path separator in Dos. Fine, once you get used to it. A perfectly stupid idea nonetheless. |
| 07:14.46 | beewoolie | yes I can. |
| 07:14.56 | beewoolie | It is a poorly conceieved idea. |
| 07:15.15 | beewoolie | Kernel users don't really need it, either. Denk implemented it for his runtime tests. |
| 07:15.42 | beewoolie | Users should not need to read the manual when there is a long history of others who have implemented something similar. |
| 07:15.45 | Jacmet | a matter of opinion as always - I find it a relatively nice and simple solution |
| 07:15.54 | beewoolie | Solution to what? |
| 07:16.20 | Jacmet | attaching metadata to a binary blob |
| 07:16.29 | beewoolie | ...and I wrote another boot loader so that I could make progress instead of reading his childish rants. |
| 07:16.46 | beewoolie | In what way is this metadata interesting? it isn't even generalized? |
| 07:17.11 | beewoolie | I cannot add comments or other arbitrary data. |
| 07:17.20 | Jacmet | start address, image type, checksum, compression mode, .. |
| 07:17.33 | beewoolie | Don't need any of that for kernel images. |
| 07:18.00 | beewoolie | Start address is always the first word. Image type is irrelevent. Checksum isn't useful because the decompressor already checks it....and so on. |
| 07:18.16 | Jacmet | compression and crc are interestring if you don't use a zImage |
| 07:18.27 | beewoolie | I've never wanted to use anything else. |
| 07:18.56 | beewoolie | And, as I said, it is very interesting to Denk and his customers who write stand-alone applications. |
| 07:19.06 | beewoolie | Not very interesting to kernel users. |
| 07:19.45 | Jacmet | It's nice if you already have zlib/bzip2/lzma support in yout bootloader (for E.G. fpga bitstreams) instead of ending up with yet another copy of zlib for each image |
| 07:21.21 | Jacmet | but it's fine that you wrote a new loader - I was just wondering what you found lacking in the others |
| 07:21.22 | beewoolie | For the kernel, this isn't that interesting. FPGA, sure. |
| 07:21.56 | beewoolie | I probably have my 'I hate uboot' list around here somewhere, right next to the I hate blob list. |
| 07:22.10 | Jacmet | heh ;) |
| 07:22.34 | Jacmet | but we do quite some eCos stuff, so that's probably why ;) |
| 07:22.37 | beewoolie | Too bad you weren't around earlier. |
| 07:22.57 | beewoolie | Someone was trying to get reboot to init 128MB slugs. As far as I can tell, no one was successful. |
| 07:23.31 | Jacmet | odd, it shouldn't be more than a few lines of changes |
| 07:23.45 | beewoolie | Search me. |
| 07:24.59 | beewoolie | tee hee. That tickles. |
| 07:25.13 | Jacmet | ;) |
| 07:26.13 | Jacmet | ok, I'll get jtag going then an recompile Redboot with some debugging prints to figure out the ATAG problem.. |
| 07:30.38 | Jacmet | beewoolie: there's btw a little typo in README_build: Recusring Directories |
| 07:31.18 | beewoolie | In APEX? |
| 07:31.52 | Jacmet | beewoolie: yes, in 1.3.0 |
| 07:32.03 | beewoolie | I'll check on it. thx. |
| 07:32.43 | beewoolie | One of the main reasons I wrote APEX has to do with the way it extends things like ATAGS. Have you looked a the APEX code? |
| 07:33.01 | Jacmet | beewoolie: only for around 30secs by now ;) |
| 07:33.17 | Jacmet | beewoolie: I'll have a look - file? |
| 07:33.19 | beewoolie | It uses linker sections the way that the kernel does. |
| 07:33.39 | beewoolie | Look at the linker script and then look at some of the services and commands. |
| 07:34.34 | Jacmet | ahh, ok - like Redboot does it for new commands and so on |
| 07:35.10 | beewoolie | src/arch-arm/entry/apex.lds.S, src/apex/*.c |
| 07:35.26 | beewoolie | Redboot doesn't use it for the startup code. Last I looked, it was all macros. |
| 07:36.11 | beewoolie | I also don't think that redboot can start from RAM with the same image it runs from flash. |
| 07:37.18 | Jacmet | beewoolie: no, Redboot is position dependent - and there's different configurations for RAM/ROM/ROMRAM startup (memcontroller init, ..) |
| 07:37.22 | beewoolie | rwhitby-away: BTW, I'm building a new compiler. |
| 07:37.56 | beewoolie | rwhitby-away: The latest crosstool wants to build 4.1.2 for ARM. So, I'll try that one first. |
| 07:38.16 | beewoolie | Jacmet: The Logic PD loader is the same way. Very inconvenient. |
| 07:38.34 | beewoolie | I was going for easy of use. |
| 07:42.35 | beewoolie | Jacmet: One of the things I wanted to do was be able to run from SRAM. The automatic reloc code makes it easy to bootstrap without erasing flash in the first go. |
| 07:43.29 | beewoolie | Also, the program image is immutable. The code as it appears in flash is the same code in SDRAM and can be written from SDRAM directly to flash. blob doesn't work this way. |
| 07:47.16 | Jacmet | beewoolie: that's indeed a nice feature |
| 07:48.11 | Jacmet | with Redboot you end up needing a RAM version to update a ROM version (unless you use ROMRAM) |
| 07:49.11 | beewoolie | IIRC, redboot is hampered by the x86 legacy which is much more difficult when it comes to PIC code. |
| 07:49.41 | beewoolie | ARM has very handy register handling that makes PIC calls feasible. |
| 07:50.08 | Jacmet | well, the scope is ofcause also a lot bigger than apex as redboot supports 11 archs |
| 07:50.31 | *** join/#openjtag rwhitby-treo (~upirc@rwhitby.nslu2-linux) |
| 07:50.42 | beewoolie | Just give me some time... |
| 07:51.01 | Jacmet | ;) |
| 07:51.10 | rwhitby-treo | Jacmet: have a look at Sluggo for the work so far on recompiling RedBoot |
| 07:51.41 | rwhitby-treo | dyoung was doing that work |
| 07:51.44 | beewoolie | rwhitby-treo: yo. I'm building a new toolchain. |
| 07:52.01 | rwhitby-treo | it's in the cvs at nslu.sf.net - see the wiki page |
| 07:52.12 | rwhitby-treo | beewoolie: yeah, saw that. |
| 07:52.28 | rwhitby-treo | um, gotta go - back in 45 |
| 07:52.33 | *** part/#openjtag rwhitby-treo (~upirc@rwhitby.nslu2-linux) |
| 07:54.32 | Jacmet | rwhitby-away: ok |
| 09:32.33 | DaKa2 | is there some way I can test the memory with apex? |
| 09:47.35 | beewoolie-afk | DaKa2: There's nothing explicit in the code to test ram. |
| 09:47.50 | beewoolie-afk | The best way to test it is to use it. :-) |
| 09:48.09 | DaKa2 | :) |
| 09:48.15 | DaKa2 | ok.. |
| 09:48.26 | DaKa2 | I should try and boot the kernel then.. |
| 09:48.30 | beewoolie-afk | It does search memory to make sure it has the right stuff. |
| 09:48.48 | beewoolie-afk | IOW, it makes sure that it eliminates aliased regions. |
| 09:49.01 | beewoolie-afk | Does APEX start on your target? |
| 09:49.08 | DaKa2 | should booting the kernel work when running from sdram? |
| 09:49.15 | DaKa2 | nslu2 :) |
| 09:49.42 | DaKa2 | Uncompressing Linux..........................................................crc error -- System halted |
| 09:51.18 | *** join/#openjtag cbpage (~cpage@ip68-6-39-177.sb.sd.cox.net) |
| 09:51.38 | beewoolie-afk | DaKa2: Yeah. That's what I'm looking into. |
| 09:51.58 | beewoolie-afk | I know that you folks are using a different compiler. |
| 09:52.02 | beewoolie-afk | Than I am. |
| 09:52.06 | DaKa2 | beewoolie-afk: oh.. |
| 09:52.11 | beewoolie-afk | I'm building a 3.4.4 compiler so I can test it. |
| 09:52.23 | beewoolie-afk | I've noticed that the code stream is different in subtle ways. |
| 09:52.29 | beewoolie-afk | I don't know if it breaks things. |
| 09:52.39 | DaKa2 | I used crosstool 0.38 actually, and skipped the OE cross env |
| 09:52.48 | beewoolie-afk | Ah. Which compiler are you using? |
| 09:53.12 | DaKa2 | good question... |
| 09:53.23 | beewoolie-afk | I just built gcc-3.4.4-glibc-2.3.5 |
| 09:53.36 | DaKa2 | I used gcc-3.4.0-glibc-2.3.2 |
| 09:53.39 | beewoolie-afk | It isn't in the default set of compilers that crosstool-0.38 builds for arm. |
| 09:53.49 | beewoolie-afk | Hmm. Interesting. |
| 09:54.13 | beewoolie-afk | Would you paste the version command output from APEX into pastebin for me? |
| 09:54.54 | beewoolie-afk | BTW, I'm using gcc-3.4.2-glibc-2.3.3 from crosstool-0.32 |
| 09:55.53 | DaKa2 | beewoolie-afk: http://pastebin.com/329084 |
| 09:57.23 | beewoolie-afk | thx |
| 10:04.29 | beewoolie-afk | DaKa2: Are you booting APEX from flash? |
| 10:04.56 | DaKa2 | no, sdram |
| 10:05.36 | beewoolie-afk | Um, then how are you getting 64MB of SDRAM? |
| 10:05.52 | DaKa2 | two banks of 32Mb? |
| 10:06.06 | DaKa2 | I didn't change anything in the source.. |
| 10:06.10 | beewoolie-afk | Right. Did you recompile redboot to initialize SDRAM? |
| 10:06.20 | DaKa2 | uhm, no? |
| 10:06.52 | beewoolie-afk | Maybe I'm crazy, but the machine comes with 32, right? |
| 10:06.57 | beewoolie-afk | You added some RAM. |
| 10:07.16 | DaKa2 | yes, maybe forgot to say that.. |
| 10:07.21 | DaKa2 | :) |
| 10:07.28 | beewoolie-afk | OK. So, there should only be 32MB recognizded. |
| 10:08.57 | beewoolie-afk | Can you do me a favor? I'd like to see the config on the memory controller. |
| 10:09.34 | beewoolie-afk | apex> du -4 0xcc000000#32 |
| 10:09.58 | DaKa2 | hm.. my slug no longer boots.. I think I managed to break the power on circuit... have to fix that first.. |
| 10:10.02 | DaKa2 | dammit |
| 10:10.13 | DaKa2 | it's not getting power.. |
| 10:10.29 | beewoolie-afk | sorry to hear it. |
| 10:10.51 | DaKa2 | well, I should probably be able to fix it, and then check that config |
| 10:12.24 | beewoolie-afk | According to [g2], APEX works fine in a system with 128MB of ram. I also think he's seen it working with 64MB, but of that I am not sure. |
| 10:12.50 | beewoolie-afk | I believe we're up against some sort of problem with the SDRAM init for you folks who have reconfigured memory. |
| 10:12.51 | DaKa2 | he is running one with 64Mb |
| 10:13.27 | beewoolie-afk | APEX won't do anything to the SDRAM config when it is being executed from SDRAM since that could be fatal. |
| 10:15.03 | beewoolie-afk | I'm gonna hafta bust my slug appart again so I can test this running from ram thing. |
| 10:18.27 | beewoolie-afk | DaKa2: Is your slug de-underclocked, too? |
| 10:18.56 | DaKa2 | beewoolie-afk: yep.. |
| 10:19.20 | beewoolie-afk | I wish there were an easy way to determine that. |
| 10:19.24 | beewoolie-afk | From software. |
| 10:21.15 | beewoolie-afk | sleep time. |
| 10:21.17 | beewoolie-afk | cheers |
| 10:21.28 | *** part/#openjtag beewoolie-afk (~beewoolie@florence.buici.com) |
| 10:48.40 | *** join/#openjtag dyoung (~dyoung-aw@dyoung.nslu2-linux) |
| 10:53.21 | DaKa2 | now that it boots beewoolie went to sleep :-) |
| 10:56.04 | DaKa2 | just for the log so I can give it to beewoolie later: |
| 10:56.04 | DaKa2 | apex> du -4 0xcc000000#32 |
| 10:56.04 | DaKa2 | cc000000: 00000018 00000081 00000006 80000822 ........ ......." |
| 10:56.04 | DaKa2 | cc000010: 00001e17 00000a7f 00001e17 00000000 ........ ........ |
| 12:51.47 | *** join/#openjtag malfi (~malte@dsl-082-082-197-240.arcor-ip.net) |
| 13:11.28 | DaKa2 | hm.. when I compile apex for just the first bank things work and I can boot, but when I compile for both banks it fails |
| 13:12.12 | DaKa2 | I guess that is because Im running from sdram and apex cannot initialise the sdram controller for the sezzond bank.. |
| 13:12.17 | DaKa2 | seccond* |
| 13:12.43 | DaKa2 | second* |
| 13:13.13 | DaKa2 | or.. it could be that by second bank of chips is broken.. |
| 13:21.42 | *** join/#openjtag prpplague (~billybob@72.22.131.116) |
| 13:39.07 | *** join/#openjtag ka6sox (~tking@adsl-66-159-198-116.dslextreme.com) |
| 13:45.11 | *** join/#openjtag malfi (~malte@dsl-082-082-197-240.arcor-ip.net) |
| 14:09.56 | *** join/#openjtag landslide (~david@203-206-61-8.dyn.iinet.net.au) |
| 15:43.17 | *** join/#openjtag landslide (~david@203-206-61-8.dyn.iinet.net.au) |
| 15:53.11 | *** join/#openjtag landslide (landslide@203-206-61-8.dyn.iinet.net.au) |
| 17:01.57 | *** join/#openjtag ByronT (ByronT@ByronT.nslu2-linux) |
| 20:01.20 | prpplague | is there nothing out there OSS wise that will allow me to step through code on the device letting me see the registers? |
| 22:19.40 | *** join/#openjtag prpplague (~billybob@72.22.131.116) |
| 23:56.36 | *** join/#openjtag nslu2-log_ (dyoung@dyoung.nslu2-linux) |