**** BEGIN LOGGING AT Wed Aug 03 23:59:56 2005
Aug 04 00:01:54 <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)
Aug 04 00:02:18 <beewoolie> How do you mean?  Have you checked the source?
Aug 04 00:02:53 <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 ;)
Aug 04 00:03:17 <beewoolie> You're right.  I'm less than interested.
Aug 04 00:03:22 <Jacmet> beewoolie: yes, I checked the nslu2 sources from linksys - presumably that's what is in there
Aug 04 00:03:37 <Jacmet> beewoolie ;)
Aug 04 00:03:51 <beewoolie> It is possible that the nslu2 version doesn't use that code.
Aug 04 00:03:58 <beewoolie> That's part of the reason that I don't like redboot.
Aug 04 00:04:05 <beewoolie> It's really hard to tell what code is being executed.
Aug 04 00:04:19 <Jacmet> beewoolie: what was actually your motivation for writing yet another bootloader?
Aug 04 00:04:27 <beewoolie> The use so many macros that it requires a complete understanding of the code in order to modify it.
Aug 04 00:04:37 <beewoolie> since you asked, no
Aug 04 00:04:55 <beewoolie> I write APEX because blob suffers from some of the same problems.
Aug 04 00:05:11 <beewoolie> On my targets, the Sharp LH processors, I had a choice between blob and uboot.
Aug 04 00:05:30 <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
Aug 04 00:05:32 <beewoolie> Both are quite awful because of how difficult they are to configure.
Aug 04 00:05:47 <beewoolie> I call that overdesign.
Aug 04 00:06:09 <beewoolie> It doesn't cope with the sorts of things that I care about.
Aug 04 00:06:21 <beewoolie> I want to be able to add and remove features quickly and reliably.
Aug 04 00:06:22 <Jacmet> well, uboot isn't called the universal bootloader for nothing ;)
Aug 04 00:06:40 <beewoolie> Uh huh.  I've had plenty of experience with it and the author.
Aug 04 00:06:49 <beewoolie> It has some of the most irritating features.
Aug 04 00:07:00 <beewoolie> For example, it requires that all kernel images be prefixed with a header.
Aug 04 00:07:03 <beewoolie> Blech.
Aug 04 00:07:11 <Jacmet> beewoolie: come on, it's always fun to read wdenx's postings ;)
Aug 04 00:08:04 <Jacmet> beewoolie: well, that's just to keep metadata - I find it kinda neat - it's kinda similar to the FIS in redboot
Aug 04 00:08:05 <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.
Aug 04 00:08:25 <beewoolie> That is a perfect example of an overgeneralization.
Aug 04 00:08:45 <beewoolie> A small group of users who like and need the feature are inconvenienced by it.
Aug 04 00:09:16 <Jacmet> true - he's hard, but I guess he needs to be to keep it from getting messy
Aug 04 00:09:27 <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.
Aug 04 00:09:35 <beewoolie> There is no reason for his tantrum.
Aug 04 00:09:46 <beewoolie> A simple script to strip the whitespace would have sufficed.
Aug 04 00:09:53 <beewoolie> Moreover, it is a trite complaint.
Aug 04 00:10:13 <beewoolie> APEX uses the kernel build system and it's configurator.
Aug 04 00:10:20 <beewoolie> Much much easier to work with.
Aug 04 00:10:27 <Jacmet> beewoolie: I don't see much difference between having the metadata before or after the image
Aug 04 00:10:29 <beewoolie> And, the build process is nearly optimal.
Aug 04 00:10:41 <beewoolie> Append doesn't mean 'after'.  
Aug 04 00:11:08 <Jacmet> what do you mean then?
Aug 04 00:11:09 <beewoolie> The metadata could be a prefix on the file with a jump instruction to the real first intruction of the file.
Aug 04 00:11:56 <beewoolie> append: To fix to; attach: append a charm to the bracelet.
Aug 04 00:12:23 <Jacmet> beewoolie: yes it could, but as the uImage header is always 64bytes you could just execute from there
Aug 04 00:12:24 <beewoolie> A magic number in the file would let the metadata be recognizable.
Aug 04 00:12:34 <beewoolie> You miss the point.
Aug 04 00:12:48 <beewoolie> Kernel images are used in a uniform manner in every other situation.
Aug 04 00:13:08 <beewoolie> uImages are the *only* ones that don't execute from the first instruction.
Aug 04 00:13:19 <beewoolie> First word, that is.
Aug 04 00:13:47 <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.
Aug 04 00:14:23 <Jacmet> beewoolie: well, you cannot blaim uboot for the fact that users don't rtfm ;)
Aug 04 00:14:37 <beewoolie> it's like the path separator in Dos.  Fine, once you get used to it.  A perfectly stupid idea nonetheless.
Aug 04 00:14:42 <beewoolie> yes I can.
Aug 04 00:14:52 <beewoolie> It is a poorly conceieved idea.
Aug 04 00:15:11 <beewoolie> Kernel users don't really need it, either.  Denk implemented it for his runtime tests.
Aug 04 00:15:38 <beewoolie> Users should not need to read the manual when there is a long history of others who have implemented something similar.
Aug 04 00:15:41 <Jacmet> a matter of opinion as always - I find it a relatively nice and simple solution
Aug 04 00:15:50 <beewoolie> Solution to what?
Aug 04 00:16:16 <Jacmet> attaching metadata to a binary blob
Aug 04 00:16:25 <beewoolie> ...and I wrote another boot loader so that I could make progress instead of reading his childish rants.
Aug 04 00:16:42 <beewoolie> In what way is this metadata interesting?  it isn't even generalized?
Aug 04 00:17:07 <beewoolie> I cannot add comments or other arbitrary data.  
Aug 04 00:17:15 <Jacmet> start address, image type, checksum, compression mode, ..
Aug 04 00:17:29 <beewoolie> Don't need any of that for kernel images.
Aug 04 00:17:56 <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.
Aug 04 00:18:12 <Jacmet> compression and crc are interestring if you don't use a zImage
Aug 04 00:18:23 <beewoolie> I've never wanted to use anything else.
Aug 04 00:18:52 <beewoolie> And, as I said, it is very interesting to Denk and his customers who write stand-alone applications.
Aug 04 00:19:02 <beewoolie> Not very interesting to kernel users.
Aug 04 00:19:41 <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
Aug 04 00:21:17 <Jacmet> but it's fine that you wrote a new loader - I was just wondering what you found lacking in the others
Aug 04 00:21:18 <beewoolie> For the kernel, this isn't that interesting.  FPGA, sure.   
Aug 04 00:21:52 <beewoolie> I probably have my 'I hate uboot' list around here somewhere, right next to the I  hate blob list.
Aug 04 00:22:06 <Jacmet> heh ;)
Aug 04 00:22:12 * Jacmet actually likes redboot
Aug 04 00:22:30 <Jacmet> but we do quite some eCos stuff, so that's probably why ;)
Aug 04 00:22:33 <beewoolie> Too bad you weren't around earlier.
Aug 04 00:22:53 <beewoolie> Someone was trying to get reboot to init 128MB slugs.  As far as I can tell, no one was successful.
Aug 04 00:23:27 <Jacmet> odd, it shouldn't be more than a few lines of changes
Aug 04 00:23:41 <beewoolie> Search me.
Aug 04 00:24:41 * Jacmet greps beewoolie ..
Aug 04 00:24:55 <beewoolie> tee hee.  That tickles.
Aug 04 00:25:09 <Jacmet> ;)
Aug 04 00:26:09 <Jacmet> ok, I'll get jtag going then an recompile Redboot with some debugging prints to figure out the ATAG problem..
Aug 04 00:30:34 <Jacmet> beewoolie: there's btw a little typo in README_build: Recusring Directories
Aug 04 00:31:14 <beewoolie> In APEX?
Aug 04 00:31:48 <Jacmet> beewoolie: yes, in 1.3.0
Aug 04 00:31:59 <beewoolie> I'll check on it.  thx.
Aug 04 00:32:39 <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?
Aug 04 00:32:57 <Jacmet> beewoolie: only for around 30secs by now ;)
Aug 04 00:33:13 <Jacmet> beewoolie: I'll have a look - file?
Aug 04 00:33:15 <beewoolie> It uses linker sections the way that the kernel does.
Aug 04 00:33:35 <beewoolie> Look at the linker script and then look at some of the services and commands.
Aug 04 00:34:30 <Jacmet> ahh, ok - like Redboot does it for new commands and so on
Aug 04 00:35:06 <beewoolie> src/arch-arm/entry/apex.lds.S, src/apex/*.c
Aug 04 00:35:22 <beewoolie> Redboot doesn't use it for the startup code.  Last I looked, it was all macros.
Aug 04 00:36:07 <beewoolie> I also don't think that redboot can start from RAM with the same image it runs from flash.
Aug 04 00:37:14 <Jacmet> beewoolie: no, Redboot is position dependent - and there's different configurations for RAM/ROM/ROMRAM startup (memcontroller init, ..)
Aug 04 00:37:18 <beewoolie> rwhitby-away: BTW, I'm building a new compiler.
Aug 04 00:37:52 <beewoolie> rwhitby-away: The latest crosstool wants to build 4.1.2 for ARM.  So, I'll try that one first.
Aug 04 00:38:12 <beewoolie> Jacmet: The Logic PD loader is the same way.  Very inconvenient.
Aug 04 00:38:30 <beewoolie> I was going for easy of use.
Aug 04 00:42:31 <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.
Aug 04 00:43:25 <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.
Aug 04 00:47:12 <Jacmet> beewoolie: that's indeed a nice feature
Aug 04 00:48:07 <Jacmet> with Redboot you end up needing a RAM version to update a ROM version (unless you use ROMRAM)
Aug 04 00:49:07 <beewoolie> IIRC, redboot is hampered by the x86 legacy which is much more difficult when it comes to PIC code.
Aug 04 00:49:37 <beewoolie> ARM has very handy register handling that makes PIC calls feasible.
Aug 04 00:50:04 <Jacmet> well, the scope is ofcause also a lot bigger than apex as redboot supports 11 archs
Aug 04 00:50:38 <beewoolie> Just give me some time...
Aug 04 00:50:57 <Jacmet> ;)
Aug 04 00:51:06 <rwhitby-treo> Jacmet: have a look at Sluggo for the work so far on recompiling RedBoot
Aug 04 00:51:37 <rwhitby-treo> dyoung was doing that work
Aug 04 00:51:40 <beewoolie> rwhitby-treo: yo.  I'm building a new toolchain.
Aug 04 00:51:57 <rwhitby-treo> it's in the cvs at nslu.sf.net - see the wiki page
Aug 04 00:52:08 <rwhitby-treo> beewoolie: yeah, saw that.
Aug 04 00:52:24 <rwhitby-treo> um, gotta go - back in 45
Aug 04 00:54:28 <Jacmet> rwhitby-away: ok
Aug 04 02:32:29 <DaKa2> is there some way I can test the memory with apex?
Aug 04 02:47:31 <beewoolie-afk> DaKa2: There's nothing explicit in the code to test ram.
Aug 04 02:47:45 <beewoolie-afk> The best way to test it is to use it.  :-)
Aug 04 02:48:05 <DaKa2> :)
Aug 04 02:48:10 <DaKa2> ok..
Aug 04 02:48:22 <DaKa2> I should try and boot the kernel then..
Aug 04 02:48:26 <beewoolie-afk> It does search memory to make sure it has the right stuff.
Aug 04 02:48:43 <beewoolie-afk> IOW, it makes sure that it eliminates aliased regions.
Aug 04 02:48:57 <beewoolie-afk> Does APEX start on your target?
Aug 04 02:49:04 <DaKa2> should booting the kernel work when running from sdram?
Aug 04 02:49:11 <DaKa2> nslu2 :)
Aug 04 02:49:38 <DaKa2> Uncompressing Linux..........................................................crc error -- System halted
Aug 04 02:51:34 <beewoolie-afk> DaKa2: Yeah.  That's what I'm looking into.
Aug 04 02:51:54 <beewoolie-afk> I know that you folks are using a different compiler.
Aug 04 02:51:57 <beewoolie-afk> Than I am.
Aug 04 02:52:02 <DaKa2> beewoolie-afk: oh..
Aug 04 02:52:07 <beewoolie-afk> I'm building a 3.4.4 compiler so I can test it.
Aug 04 02:52:19 <beewoolie-afk> I've noticed that the code stream is different in subtle ways.
Aug 04 02:52:25 <beewoolie-afk> I don't know if it breaks things.
Aug 04 02:52:34 <DaKa2> I used crosstool 0.38 actually, and skipped the OE cross env
Aug 04 02:52:44 <beewoolie-afk> Ah.  Which compiler are you using?
Aug 04 02:53:08 <DaKa2> good question...
Aug 04 02:53:19 <beewoolie-afk> I just built  gcc-3.4.4-glibc-2.3.5
Aug 04 02:53:32 <DaKa2> I used gcc-3.4.0-glibc-2.3.2
Aug 04 02:53:35 <beewoolie-afk> It isn't in the default set of compilers that crosstool-0.38 builds for arm.
Aug 04 02:53:44 <beewoolie-afk> Hmm.  Interesting.
Aug 04 02:54:09 <beewoolie-afk> Would you paste the version command output from APEX into pastebin for me?
Aug 04 02:54:50 <beewoolie-afk> BTW, I'm using gcc-3.4.2-glibc-2.3.3 from crosstool-0.32
Aug 04 02:55:49 <DaKa2> beewoolie-afk: http://pastebin.com/329084
Aug 04 02:57:19 <beewoolie-afk> thx
Aug 04 03:04:25 <beewoolie-afk> DaKa2: Are you booting APEX from flash?
Aug 04 03:04:52 <DaKa2> no, sdram
Aug 04 03:05:32 <beewoolie-afk> Um, then how are you getting 64MB of SDRAM?
Aug 04 03:05:48 <DaKa2> two banks of 32Mb?
Aug 04 03:06:02 <DaKa2> I didn't change anything in the source..
Aug 04 03:06:06 <beewoolie-afk> Right.  Did you recompile redboot to initialize SDRAM?
Aug 04 03:06:16 <DaKa2> uhm, no?
Aug 04 03:06:48 <beewoolie-afk> Maybe I'm crazy, but the machine comes with 32, right?
Aug 04 03:06:53 <beewoolie-afk> You added some RAM.
Aug 04 03:07:12 <DaKa2> yes, maybe forgot to say that..
Aug 04 03:07:17 <DaKa2> :)
Aug 04 03:07:24 <beewoolie-afk> OK.  So, there should only be 32MB recognizded.
Aug 04 03:08:53 <beewoolie-afk> Can you do me a favor?  I'd like to see the config on the memory controller.
Aug 04 03:09:30 <beewoolie-afk> apex> du -4 0xcc000000#32
Aug 04 03:09:54 <DaKa2> hm.. my slug no longer boots.. I think I managed to break the power on circuit... have to fix that first..
Aug 04 03:09:57 <DaKa2> dammit
Aug 04 03:10:09 <DaKa2> it's not getting power..
Aug 04 03:10:25 <beewoolie-afk> sorry to hear it.
Aug 04 03:10:47 <DaKa2> well, I should probably be able to fix it, and then check that config
Aug 04 03:12:20 <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.
Aug 04 03:12:46 <beewoolie-afk> I believe we're up against some sort of problem with the SDRAM init for you folks who have reconfigured memory.
Aug 04 03:12:47 <DaKa2> he is running one with 64Mb
Aug 04 03:13:23 <beewoolie-afk> APEX won't do anything to the SDRAM config when it is being executed from SDRAM since that could be fatal.
Aug 04 03:14:59 <beewoolie-afk> I'm gonna hafta bust my slug appart again so I can test this running from ram thing.
Aug 04 03:18:23 <beewoolie-afk> DaKa2: Is your slug de-underclocked, too?
Aug 04 03:18:52 <DaKa2> beewoolie-afk: yep..
Aug 04 03:19:16 <beewoolie-afk> I wish there were an easy way to determine that.
Aug 04 03:19:20 <beewoolie-afk> From software.
Aug 04 03:21:11 <beewoolie-afk> sleep time.
Aug 04 03:21:13 <beewoolie-afk> cheers
Aug 04 03:53:17 <DaKa2> now that it boots beewoolie went to sleep :-)
Aug 04 03:55:59 <DaKa2> just for the log so I can give it to beewoolie later:
Aug 04 03:56:00 <DaKa2> apex> du -4 0xcc000000#32
Aug 04 03:56:00 <DaKa2> cc000000: 00000018 00000081  00000006 80000822  ........ ......."
Aug 04 03:56:00 <DaKa2> cc000010: 00001e17 00000a7f  00001e17 00000000  ........ ........
Aug 04 06:11:24 <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
Aug 04 06:12:08 <DaKa2> I guess that is because Im running from sdram and apex cannot initialise the sdram controller for the sezzond bank..
Aug 04 06:12:13 <DaKa2> seccond*
Aug 04 06:12:39 <DaKa2> second*
Aug 04 06:13:08 <DaKa2> or.. it could be that by second bank of chips is broken..
Aug 04 13:01:15 <prpplague> is there nothing out there OSS wise that will allow me to step through code on the device letting me see the registers?
**** BEGIN LOGGING AT Thu Aug 04 16:56:32 2005
**** BEGIN LOGGING AT Thu Aug 04 20:26:32 2005
Aug 04 20:50:24 <dyoung-web> test
Aug 04 20:51:12 <dyoung-web> This channel is now logged http://www.loglibrary.com/show_page/latest/187 .
Aug 04 20:51:14 <dyoung-web> FYI.
Aug 04 20:51:38 <dyoung-web> paid for by the generous donations of nslu2-linux users.
Aug 04 20:57:53 <dyoung-web> I have my boatload of MCP120-450's too
Aug 04 20:58:00 <dyoung-web> whoops.
**** ENDING LOGGING AT Thu Aug 04 23:59:56 2005