**** BEGIN LOGGING AT Mon Jun 20 23:59:56 2005
Jun 21 02:51:58 * jf-away entering logger mode
Jun 21 03:51:36 <bolidz> hello
Jun 21 03:51:59 <dyoung-zzzz> hi
Jun 21 03:52:02 <dyoung-zzzz> where is .ae ?
Jun 21 03:52:16 <dyoung-zzzz> Arab Emirates?
Jun 21 03:52:20 <dyoung-zzzz> hmm
Jun 21 03:52:22 <bolidz> i really dunno
Jun 21 03:53:18 <rwhitby> ANNOUNCE: no more commits to BK please, as #oe has taken a snapshot of our bk repo.
Jun 21 03:56:46 <bolidz> do you know , if there is a binary of vsftpd , compiled with ssl support ?
Jun 21 07:53:54 <kitno455> re
Jun 21 07:55:07 <kitno455> ka6sox-office, ping
Jun 21 07:55:44 <ka6sox-zzzz> kitno455, pong
Jun 21 07:56:08 <kitno455> i have an EICO 324 vac tube HF signal gen, you want it?
Jun 21 07:56:16 <kitno455> its ancient
Jun 21 07:56:25 <ka6sox-zzzz> let me think...
Jun 21 07:56:36 <ka6sox-zzzz> how's the remodel and new addition coming?
Jun 21 07:56:51 <kitno455> got first coat of primer up last night
Jun 21 07:57:35 <kitno455> already bought flooring, etc.
Jun 21 07:57:53 <kitno455> just have to install trim, flooring, and final paint
Jun 21 08:10:15 * jf-work entering logger mode
Jun 21 08:11:30 <macsat> Hi
Jun 21 08:14:17 <kitno455> hi
Jun 21 08:17:45 <macsat> jf - the status changer ;-)
Jun 21 08:20:55 <jf-work> ?
Jun 21 08:24:49 <eno> is it me or ipkg.nslu2-linux.org down?
Jun 21 08:25:01 <ka6sox-away> jf-work -> jf-logger -> jf-work
Jun 21 08:25:09 <ka6sox-away> eno..let me check
Jun 21 08:25:34 <jf-work> loosing connection to my bouncer
Jun 21 08:26:33 <ka6sox-away> eno: its up for me...what feed are you trying to get?
Jun 21 08:27:41 <eno> it's up for me again, i was trying to get oe. Could be a local DNS issue
Jun 21 08:30:57 <ka6sox-away> k
Jun 21 08:31:02 <ka6sox-away> off to the rain locker.
Jun 21 08:46:23 <jf-work> Head off for home.
Jun 21 10:10:51 <[g2]> jacques, ping
Jun 21 10:11:03 <[g2]> Tiersten, around ?
Jun 21 10:14:37 <jacques> [g2], hi
Jun 21 10:16:06 <[g2]> jacques, are you familiar with zboot_rom_text|bss ?
Jun 21 10:16:41 <[g2]> I've got a couple questions about kernel offset and the bootloader
Jun 21 10:17:17 <jacques> hmm, no I haven't come across that before :-\
Jun 21 10:17:48 <[g2]> so you haven't played with the physical address of the kernel in memory much ?
Jun 21 10:18:16 <jacques> I think a tiny bit on the gumstix, but not really
Jun 21 10:18:21 <[g2]> well thx for responding 
Jun 21 10:33:32 <NAiL> [g2]: Finished building all the packages. But gnu-config isn't built, which is a dependency of automake.
Jun 21 10:34:23 <jacques> either automake or autoconf also depends on perl
Jun 21 10:34:47 <NAiL> perl was built, atleast
Jun 21 10:34:57 <[g2]> but it doesn't run
Jun 21 10:35:07 <NAiL> ho
Jun 21 10:35:08 <NAiL> oh
Jun 21 10:35:16 <[g2]> runtime error
Jun 21 10:35:34 <NAiL> perl built natively runs though?
Jun 21 10:35:59 <[g2]> jacques, has run it and completed 100% of the tests with glibc 2.3.5 iirc
Jun 21 10:36:28 <jacques> [g2], native-built yes 100%
Jun 21 10:36:57 <jacques> I also did python and (strangely) it passed more tests with 2.3.5 (still not sure about that)
Jun 21 10:39:32 <jacques> hmm I just realized I use native differently than oe
Jun 21 10:39:45 <jacques> when I say native-built I mean on the slug
Jun 21 10:39:55 <[g2]> yeah me too
Jun 21 10:39:59 <[g2]> not oe-native
Jun 21 10:40:32 <jacques> now, if oe would built the same version of python native and cross, we wouldn't have to download two fdifferent versions at almost 8MB each
Jun 21 10:40:46 <[g2]> jacques, do you know what the ENTRY routine is for the kernel ?
Jun 21 10:40:55 <[g2]> the starting address ?
Jun 21 10:41:32 <jacques> I'm not a kernel hacker on that level - never messed with that part  :-\
Jun 21 10:48:13 <NAiL> [g2]: I'm gonna start from scratch, there might be some odd stuff left in my setup. 
Jun 21 12:28:31 <jbowler-away> [g2]: if it is a zImage it doesn't enter the kernel, rather it enters the decompressor (arch/arm/boot/compressed/head.S iirc)  I believe that is placed at the start of the image.  It's PIC - it doesn't care where it is in memory.
Jun 21 12:29:38 <[g2]> jbowler-away, that's my understanding of it too, however I think the zreladdr is hosed up
Jun 21 12:29:52 <[g2]> memory is in the right spot
Jun 21 12:30:04 <[g2]> not @ 0 but at 0x10000000
Jun 21 12:30:41 <[g2]> so I'm guessing the decompress starts, but then dies on the first write to low-memory
Jun 21 12:31:08 <jbowler-away> The memory is replicated, it should always be at 0
Jun 21 12:31:31 <jbowler-away> (unless the boot loader ran out of flash - and I don't know that the kernel can handle that.)
Jun 21 12:31:54 <[g2]> latform: Intel(R) IXDP425
Jun 21 12:31:54 <[g2]> Copyright (C) 2000, 2001, 2002, Red Hat, Inc.
Jun 21 12:31:54 <[g2]> RAM: 0x10100000-0x20000000, 0x101156a8-0x1ffdd000 available
Jun 21 12:31:54 <[g2]> FLASH: 0x50000000 - 0x51000000, 128 blocks of 0x00020000 bytes each.
Jun 21 12:31:55 <jbowler-away> (I'm assuming it's running without the MMU on)
Jun 21 12:32:15 <[g2]> I think I get the same results
Jun 21 12:32:51 <jbowler-away> Right, but the RAM memory map gets duplicated and the RedBoot startup code does write to address 0 (it copies itself from flash at 0 to DRAM then maps the DRAM back to 0)
Jun 21 12:34:18 <jbowler-away> Um, Ok - you may have a different build of RedBoot.  It can be compiled to run out of flash, in which case it should copy itself to a higher RAM address.  I don't know what the kernel does then...
Jun 21 12:34:50 <[g2]> RedBoot(tm) bootstrap and debug environment [ROM]
Jun 21 12:34:50 <[g2]> Non-certified release, version 2.00 - built 17:25:55, Dec 13 2002
Jun 21 12:35:16 <[g2]> I'd guess that's running from ROM :)
Jun 21 12:36:09 <jbowler-away> Yep, you got the flash one, here's what LinkSys ship:
Jun 21 12:36:18 <jbowler-away> RedBoot(tm) bootstrap and debug environment [ROMRAM]
Jun 21 12:37:33 <jbowler-away> 'ROMRAM' causes copy to 0, 'ROM' just copies the page table to RAM - it executes the code from flash.  The RedBoot code is very definately not PIC, so it only runs where it is compiled, which is @0
Jun 21 12:38:29 <jbowler-away> So head.S needs to zap the flash memory out of the way - the inverse of the code I added to arch/arm/mm/proc-xscale.S
Jun 21 12:39:33 <jbowler-away> (Assuming RedBoot does not do it before exec'ing the kernel)
Jun 21 12:46:52 <[g2]> jbowler-away, which code did you add ?
Jun 21 12:53:06 <jbowler-away> xscale-reset.patch
Jun 21 12:55:50 <[g2]> jbowler-away, wow you went for it :)
Jun 21 12:56:09 <jbowler-away> The comment about the page table needing to be set up is wrong.
Jun 21 12:56:48 <jbowler-away> The old code was clearly broken - it did not remap the flash - but it doesn't seem to help doing so, something else still needs to be reset.
Jun 21 12:57:23 <jbowler-away> Which is why I can't make any progress on it - I don't even know where it hangs in RedBoot.
Jun 21 12:57:46 <[g2]> it hangs before the '+'
Jun 21 12:58:02 <[g2]> which is quite early on I think
Jun 21 12:58:28 <jbowler-away> What '+'?
Jun 21 12:59:18 <[g2]> Redboot prints out a '+' almost immediatley before doing anything
Jun 21 13:01:24 <jbowler-away> Ah.  I'm not sure it executes anything, there's not really enough time or instruction space (just 8 instructions) to check address 0.
Jun 21 13:01:27 <jbowler-away> What does APEX do?
Jun 21 13:01:59 <[g2]> On the dev box ?
Jun 21 13:02:12 <[g2]> I haven't tried it as it's a different processor (425)
Jun 21 13:02:25 <[g2]> I guess they are close
Jun 21 13:02:29 <jbowler-away> On NSLU2.
Jun 21 13:02:59 <[g2]> Oh same thing I think. no led flashy
Jun 21 13:03:53 <jbowler-away> Yes, but what LEDs are on before the watchdog times out (i.e. for the first 4 seconds after disk1 and disk2 get switched on)
Jun 21 13:04:40 <[g2]> I was watching APEX the other day and Disk 1 is on then the reset and jsut the ethernet light
Jun 21 13:04:46 <[g2]> iirc
Jun 21 13:04:50 <[g2]> or no lights
Jun 21 13:06:06 <jbowler-away> jacques suggested reseting the USB stuff.  That's probably a good bet - there's probably a pending USB IRQ in the system, still I'm going to wait until I have something with JTAG...
Jun 21 13:06:54 <jbowler-away> Because then I can simply make the LEDs indicate progress (i.e. replace the stupid code which sets the digital display...)
Jun 21 13:09:07 <[g2]> if someone like Tiersten has a JTAG debugger then you should be able to just attach to the processor and see where it was at
Jun 21 13:11:02 <jbowler-away> Right, then the problem would probably be obvious.
Jun 21 13:11:34 <[g2]> well, much clearer :)
Jun 21 13:11:48 <[g2]> I'll be off for a while
Jun 21 13:11:53 <[g2]> see you guys in a bit
Jun 21 13:11:57 <[g2]> jbowler-away, thx for the help
Jun 21 18:24:04 <jp30> rwhitby, have you had a chance to look at libusb for me?
Jun 21 18:24:39 <rwhitby> jp30: I updated ftpd-topfield last night.  Can you push the new 0.5.2 version?
Jun 21 18:24:53 <rwhitby> it built against libusb, so that should be fine.
Jun 21 18:25:35 <jp30> have you checked that it works run time? the name of the libusb shared library has changed
Jun 21 18:25:55 <jp30> ...it used to lack a .so extension due to a libtool bug
Jun 21 18:25:58 <rwhitby> haven't had a chance to test it yet, as my toppy is connected to the openslug slug, and my openslug build env is in a bit of a mess at the moment
Jun 21 18:26:14 <jp30> so i read in the email list :( evil bk
Jun 21 18:27:35 <jp30> i would expect that binaries built against the new libusb should be ok - they will know the correct library name.  shall i just push both libusb and ftpd-topfield and see if users complain?
Jun 21 18:27:53 <rwhitby> yeah
Jun 21 18:28:02 <rwhitby> "Testing is for users" - Linus Torvalds 
Jun 21 18:29:55 <jp30> ok, i'll do that then.  i think it will be fine
Jun 21 23:30:33 <rwhitby> all three slugs survived the http://www.nslu2-linux.org/wiki/HowTo/ForcePowerAlwaysOn surgery
Jun 21 23:31:18 <rwhitby> big thanks to Mark Smith for sending me some parts!
Jun 21 23:40:06 <mr_claus> morning
**** ENDING LOGGING AT Tue Jun 21 23:59:56 2005