**** BEGIN LOGGING AT Thu Sep 22 02:59:56 2005
Sep 22 07:27:29 <CIA-8> 03ph5 07org.openembedded.dev * r456405c1... 10/packages/bluez/ (4 files): bluez-libs,bluez-utils: new version 2.21
Sep 22 07:27:31 <CIA-8> 03ph5 07org.openembedded.dev * rab4108f7... 10/packages/pmount/ (files/no-hal.patch pmount_0.9.4.bb): pmount: add a recipe for pmount 0.9.4
Sep 22 08:10:15 <dwery> [g2]: regardin you mail exchange w/ Lennert about mach id.. I suggest to store it somewhere in the flash of your board
Sep 22 08:10:32 <lennert> nico suggested you can script it from redboot
Sep 22 08:10:43 <lennert> make redboot write the correct value to r1 and then go instead of exec
Sep 22 08:11:35 <lennert> not sure how you'd do that though
Sep 22 08:11:51 <dwery> yes.. redboot should take this value form <somewher> and place it where's needed
Sep 22 08:15:54 <[g2]> lennert right, giving up the command line parameters to get a mach_id in is a good trade :)
Sep 22 08:16:48 <[g2]> I'll just rebuild the kernel and reflash when I want to change the cmdline params anyway
Sep 22 08:17:19 <[g2]> Hope you guys know I'm just kidding
Sep 22 08:17:21 <lennert> as to non-ixdp425 boards passing the ixdp425 machine id, the arm kernel folks say:
Sep 22 08:17:40 <lennert> "refer them to the definitive boot guide and hit them with a clue bat
Sep 22 08:17:45 <dwery> I agree.
Sep 22 08:18:09 <lennert> "certified.. ertificate for most obnoxious bootloader?"
Sep 22 08:18:12 <[g2]> can you two follow me to #nslu2 for a minute ?
Sep 22 08:18:17 <lennert> etc
Sep 22 08:18:22 <dwery> you're going to hit us? :D
Sep 22 08:18:27 <lennert> dwery: not me :)
Sep 22 08:19:12 <[g2]> no I won't hit you :)
Sep 22 08:19:22 <lennert> [g2]: hm, you want me to join that channel?
Sep 22 08:19:32 <[g2]> yeah you and dwery
Sep 22 08:19:40 <dwery> i'm there.
Sep 22 08:19:49 <lennert> hmmm ok
Sep 22 08:33:20 <bullet> lennert: why would you need to use go instead of exec? exec does set r1, and if you want to make it "scriptable", you can.
Sep 22 08:33:50 <lennert> bullet: exec puts whatever it thinks is the right machine ID in r1
Sep 22 08:33:53 <lennert> but you want to pass something else
Sep 22 08:34:18 <bullet> it puts the ID you choose at compile-time to put in r1...
Sep 22 08:48:09 <yvasilev> [g2]: ping?
Sep 22 09:00:30 <[g2]> yvasilev, pong
Sep 22 09:01:34 <yvasilev> [g2]: by any chance, do you know if there is a way to telnet into redboot in the rv routers (o the bootloader they use)?
Sep 22 09:01:56 <[g2]> yvasilev they don't use redboot
Sep 22 09:02:02 <[g2]> but you can telnet it
Sep 22 09:02:29 <[g2]> I've in a chroot my RV042
Sep 22 09:02:33 <[g2]> and RV082
Sep 22 09:02:43 <yvasilev> yes, but I want to try my firmwares without flashing/killing it
Sep 22 09:03:08 <[g2]> yvasilev, exactly... I ran my chroot from ramdisk
Sep 22 09:04:14 <[g2]> I forget exactly what I did, I could figure it out again but basically I created a ram partition and untarred my rootfs there and chrooted into it
Sep 22 09:04:16 <yvasilev> but it is a chroot, no custom kernel, no custom init
Sep 22 09:04:23 <[g2]> all statically compiled of course
Sep 22 09:04:35 <[g2]> exactly, a chroot
Sep 22 09:04:35 <yvasilev> yes, that I can do
Sep 22 09:04:58 <[g2]> they use a different bootloader
Sep 22 09:05:05 <yvasilev> and actually you can use dynamicly linked bins as well
Sep 22 09:05:20 <[g2]> well space is an issue :)
Sep 22 09:05:51 <yvasilev> ouch, that is bad do you know what is the bootloader they have used?
Sep 22 09:06:16 <yvasilev> use uclibc ;-)
Sep 22 09:06:26 <[g2]> The Loft is going well, I'll be verifying the JTAG soon.  I'd like to hookup JTAG on the RV042/082 and replace its firmware
Sep 22 09:06:47 <[g2]> s/replace/fully replace/
Sep 22 09:07:14 <yvasilev> let me know if you manage to connect jtag ;-)
Sep 22 09:07:20 <[g2]> It very high on my todo list right after Loft stuff
Sep 22 09:07:28 <bullet> [g2]: what jtag adapter do you have?
Sep 22 09:07:38 <[g2]> I've got a couple
Sep 22 09:07:51 <[g2]> A Raven, and some parallel adapters
Sep 22 09:08:19 <bullet> how fast is the raven at flashing 512kb?
Sep 22 09:08:20 <[g2]> A guy in #openjtag is build a USB based one
Sep 22 09:08:28 <[g2]> bullet dunno yet
Sep 22 09:09:00 <[g2]> the guy from #openjtag was able to dl directly into the mini I cache and run the program
Sep 22 09:09:06 <bullet> i've read somewhere, a custom built parallel adapter takes ~45 minutes to program the whole nslu2
Sep 22 09:09:18 <[g2]> bullet nod for 256K
Sep 22 09:09:48 <[g2]> The smart think to do is just load something like APEX into memory
Sep 22 09:10:03 <bullet> and that'll be fast? good.
Sep 22 09:10:42 <[g2]> bullet there are lots of options
Sep 22 09:12:12 <yvasilev> [g2]: do you have serial on your rv0?2s?
Sep 22 09:13:18 <[g2]> not yet
Sep 22 09:13:35 <[g2]> but there's a 3v level shifter I'm using from digilentinc
Sep 22 09:13:43 <[g2]> its $12.95
Sep 22 09:13:52 <[g2]> works for the NSLU2
Sep 22 09:14:02 <[g2]> It's just hooking up 4 pins
Sep 22 09:14:40 <[g2]> I'll need to ping the guy that did a bunch of stuff on the RV back in march '05
Sep 22 09:15:17 <[g2]> I'm gonna head of for lunch.... bbiab
Sep 22 09:15:19 <[g2]> cheers
Sep 22 10:12:37 <lennert> [g2]: sorry, i got dragged away
Sep 22 10:12:49 <lennert> [g2]: imho, either you store the machine id in redboot itself or in its config area in some way
Sep 22 10:13:03 <lennert> [g2]: if the former is not feasible (manufacturing, whatever), the latter is the only option
Sep 22 10:13:11 <dwery> "Just do it!" (tm) :-D
Sep 22 10:14:10 <lennert> dwery: trademark infringer!!  the tiaa (trademark industry association of america) is going to sue you!!
Sep 22 10:14:48 <dwery> :)
Sep 22 10:48:43 <dwery> lennert: ping
Sep 22 10:49:24 <lennert> pong
Sep 22 10:49:34 <[g2]> tennis anyone ?
Sep 22 10:50:04 <lennert> ping pong ping pong ping pong
Sep 22 10:50:11 <dwery> :)
Sep 22 10:50:18 <dwery> lennert: about the ixp4xx regs patch
Sep 22 10:50:30 <dwery> you said it has been fixed upstream. in which kernel version?
Sep 22 10:50:49 <lennert> i looked at 2.6.13
Sep 22 10:50:50 <lennert> let me recheck
Sep 22 10:51:10 <lennert> #define IXP4XX_EXP_CFG_BASE_VIRT        (0xFFBFD000)
Sep 22 10:51:13 <lennert> #define IXP4XX_PCI_CFG_BASE_VIRT        (0xFFBFE000)
Sep 22 10:51:59 <dwery> are thos in 2.6.13?
Sep 22 10:52:04 <lennert> yeah
Sep 22 10:52:07 <lennert> let me check the history of that file
Sep 22 10:54:03 <dwery> uh.. then the old patches I sent to the list reverts that file to the old situation :) better I removeit
Sep 22 10:55:20 <dwery> the patch list is slowly shrinking...
Sep 22 10:55:42 <lennert> dwery: good thing
Sep 22 10:56:39 <dwery> let;s talk about the copy from patch
Sep 22 10:57:03 <[g2]> lennert where can one check the history of a file ?
Sep 22 10:57:18 <lennert> [g2]: www.kernel.org/git
Sep 22 10:57:23 <lennert> [g2]: but it's really slow at the moment
Sep 22 10:58:32 <dwery> why this get_unaligned() was added?
Sep 22 11:01:50 <lennert> dwery: if those are really unaligned accesses, the patch is legitimate, and you should send it to dsaxena and/or linux-mtd
Sep 22 11:02:08 <dwery> lennert: who can confirm that?
Sep 22 11:02:48 <lennert> dwery: revert the patch, and see if the System count in /proc/cpu/alignment is > 0 after boot
Sep 22 11:02:56 <dwery> ok .
Sep 22 11:02:57 <dwery> thanks.
Sep 22 11:03:08 <dwery> brb for more discussions :)
Sep 22 11:03:36 <[g2]> lennert that rings a bell
Sep 22 11:03:52 <[g2]> I think it was an mtd issue
Sep 22 11:04:06 <cheef_daniel> does somebody know how to configure the perl-locals correctly for the NSLU2?
Sep 22 11:04:24 <[g2]> there was a mtd-tools issue at one point
Sep 22 11:06:36 <cheef_daniel> there were error like  warning: Please check that your locale settings LANGUAGE=(unset), LANG=(unset), LC_ALL=(unset)...
Sep 22 11:07:02 <cheef_daniel> ...are supported and installed on your system. 
Sep 22 11:10:39 <lennert> cheef_daniel: strange
Sep 22 11:10:55 <lennert> cheef_daniel: do you have the 'locales' package installed?
Sep 22 11:10:59 <dwery> [g2]: so it's that patch legitimate?
Sep 22 11:12:21 <NAiL> cheef_daniel: how are you trying to build perl? Are you using the Master Makefile?
Sep 22 11:12:50 <NAiL> or are you building it natively?
Sep 22 11:12:51 <[g2]> dwery I can't remember if it's there because we were seen unaligned access in the system, or it was the mtd-change.  I'm 80-90% sure it was one of those two issues.
Sep 22 11:13:17 <dwery> [g2]: ok, i'll remove it and see if I can notice any change.
Sep 22 11:13:45 <[g2]> I don't know if we've got the history for that file as we've gone through the BK to monotone change
Sep 22 11:14:30 <[g2]> there was a big MTD issue with NOR flash but it may have just been a mtd-tools issue
Sep 22 11:20:39 <dwery> I've noticed the kernel tries to initialize two serial ports. the second one obviously fails. 
Sep 22 11:22:40 <[g2]> dwery on the slug you can RX only on the second port
Sep 22 11:22:59 <[g2]> TX is not brought out, but RX for the second port is
Sep 22 11:23:01 <dwery> but then why the kernel gives this message?
Sep 22 11:23:48 <[g2]> I thought the second port was commented out
Sep 22 11:23:57 <dwery> let me check
Sep 22 11:25:12 <dwery> ttyS0 at MMIO 0xc8000000 (irq = 15) is a XScale
Sep 22 11:25:12 <dwery> ttyS1 at MMIO 0xc8001000 (irq = 13) is a XScale
Sep 22 11:25:12 <dwery> serial8250 serial8250.0: unable to register port at index 2 (IOc01fefe0 MEMc0231d88 IRQ-1071440504): -28
Sep 22 11:25:15 <dwery> index 2
Sep 22 11:25:26 <NAiL> dwery: what board do you have?
Sep 22 11:25:31 <dwery> I think the structure has not been properly initialized
Sep 22 11:25:35 <NAiL> because I only have ttyS0
Sep 22 11:31:56 <dwery> about the mtd shutdown. If someone writes a replacement, I'll be happy to include it.
Sep 22 11:33:04 <lennert> dwery: you don't have a null entry at the end of the platform initialiser
Sep 22 11:33:11 <lennert> dwery: so it fetches index 2, 3, 4, etc
Sep 22 11:33:22 <dwery> lennert: I imagined something like that :)
Sep 22 11:33:32 <lennert> see arch/arm/mach-ixp2000/core.c
Sep 22 11:33:38 <lennert> you need a  { }, on the last line
Sep 22 11:33:43 <lennert> grep for ixp2000_serial_port
Sep 22 11:35:52 <dwery> lennert: thanks
Sep 22 11:51:59 <CIA-8> 03koen 07org.openembedded.dev * r7d3d2109... 10/packages/pcmcia-cs/ (files/arm/pcmcia pcmcia-cs-3.2.8/pcic-extra.patch): packages/pcmcia-cs/: apply patches from #287
Sep 22 11:52:02 <CIA-8> 03koen 07org.openembedded.dev * r2e0e7cea... 10/packages/pcmcia-cs/pcmcia-cs_3.2.8.bb: packages/pcmcia-cs/pcmcia-cs_3.2.8.bb: bump PR after last change
Sep 22 11:52:04 <CIA-8> 03koen 07org.openembedded.dev * rf91c1078... 10/packages/blueprobe/blueprobe_0.15.bb: packages/blueprobe/: add 0.15
Sep 22 12:03:01 <dwery> it seems that without the get_unaligned() it does not detect the redboot partition table
Sep 22 12:05:45 <dwery> so I vote to keep that :)
Sep 22 12:06:06 <NAiL> Good Idea 
Sep 22 12:06:15 <NAiL> Does it affect anything else though?
Sep 22 12:06:21 <dwery> it seems not
Sep 22 12:07:09 <lennert> dwery: that is a kernel bug then
Sep 22 12:07:14 <lennert> dwery: what kernel version are you using?
Sep 22 12:07:17 <dwery> 2.6.13.1
Sep 22 12:07:37 <dwery> it may be a combination of the get_unaligned and the le patch.
Sep 22 12:07:46 <lennert> dwery: is get_unaligned always using LE byte order?
Sep 22 12:07:54 <lennert> dwery: i still think it's a kernel bug
Sep 22 12:08:06 <dwery> can someone BE please try 2.6.13.1 with and without the 10-ixp4xx-copy-from.patch ?
Sep 22 12:09:57 <dwery> any volunteer?
Sep 22 12:11:52 <NAiL> I do wish I had serial right now
Sep 22 12:11:59 <NAiL> I'll fix my cable later tonight
Sep 22 12:12:08 <NAiL> then I can test stuff
Sep 22 12:13:27 <dwery> thanks mate
Sep 22 12:13:49 <dwery> 1) compile 2.6.13.1 with the latest set of patches is ubmitted to the list
Sep 22 12:13:58 <dwery> 2) verify it works
Sep 22 12:14:08 <dwery> 3) remove only the copy patch
Sep 22 12:14:12 <dwery> 4) verify again
Sep 22 12:14:52 <jbowler> Where are the patches?
Sep 22 12:15:28 <dwery> on the mailing list
Sep 22 12:18:38 <dwery> have to go now... i'll read the logs later this night
Sep 22 12:21:33 <CIA-8> 03koen 07org.openembedded.dev * r840187fe... 10/packages/keylaunch/files/keylaunchrc: packages/keylaunch/files/keylaunchrc: apply patches from #337
Sep 22 12:21:36 <CIA-8> 03koen 07org.openembedded.dev * r12c78fd2... 10/packages/xserver/xserver-kdrive_20050207.bb: packages/xserver/xserver-kdrive_20050207.bb: enable apm hack for h3900 too
Sep 22 12:21:38 <CIA-8> 03koen 07org.openembedded.dev * r73e27d19... 10/packages/netbase/ (netbase/interfaces netbase_4.21.bb): packages/netbase/netbase/interfaces: make usb0 behave like it's 2.4 counterpart, bump PR in .bb
Sep 22 12:21:41 <CIA-8> 03koen 07org.openembedded.dev * r0baef97d... 10/packages/blueprobe/ (blueprobe-0.15/hx4700.patch blueprobe_0.15.bb): packages/blueprobe/blueprobe_0.15.bb: add patch from http://handhelds.org/~bugzilla/show_bug.cgi?id=1398
Sep 22 13:02:49 <CIA-8> 03jbowler 07org.openembedded.dev * rf6740acf... 10/packages/upslug/ (6 files): upslug2: move to upslug2_4, move to file (not cvs) release
Sep 22 13:02:52 <CIA-8> 03jbowler 07org.openembedded.dev * r26162f44... 10/packages/devio/ (11 files): devio: move to devio_1.0, move to a file (not cvs) release
Sep 22 13:02:55 <CIA-8> 03jbowler 07org.openembedded.dev * rca72f385... 10/packages/binutils/ (3 files in 2 dirs): (log message trimmed)
Sep 22 13:02:55 <CIA-8> binutils_2.16: patch thumb trampoline and glue code generation
Sep 22 13:02:55 <CIA-8> This patch fixes problems with the ARM thumb specific code generation. It
Sep 22 13:02:55 <CIA-8> also adds debugging to bfd/elf32-arm.c to detect ref counting problems -
Sep 22 13:02:55 <CIA-8> one error message can fire in theory in the absence of thumb support if
Sep 22 13:02:57 <CIA-8> a union refcount field is used to refcount when it is set to something else.
Sep 22 13:02:59 <CIA-8> The error should be ignorable, in that the code should not have changed in
Sep 22 13:06:44 <CIA-8> 03jbowler 07org.openembedded.dev * r969c909f... 10/packages/gcc/ (7 files in 2 dirs): 
Sep 22 13:06:44 <CIA-8> gcc_3.4.4: updated thumb patches
Sep 22 13:06:44 <CIA-8> The four previous thumb related patch files have been combined into one
Sep 22 13:06:44 <CIA-8> and simplified. Additional problems with call_via_rX functions being
Sep 22 13:06:44 <CIA-8> called via the PLT have been fixed (the functions can no longer be called
Sep 22 13:06:44 <CIA-8> this way - they are hidden). Unnecessary adds of exports of these
Sep 22 13:06:46 <CIA-8> functions from libgcc have been removed.
Sep 22 13:06:50 <CIA-8> 03jbowler 07org.openembedded.dev * rd8d3e2d9... 10/ (8 files in 3 dirs): 
Sep 22 13:06:52 <CIA-8> uclibc_0.9.28: fix thumb support to allow thumb uclibc
Sep 22 13:06:54 <CIA-8> This, together with the fixes in gcc and binutils, allows a system to
Sep 22 13:06:56 <CIA-8> be build with thumb libgcc and libuClibc (etc). ucslugc is changed to
Sep 22 13:06:58 <CIA-8> release 2 and to use thumb compilation of these modules.
Sep 22 13:07:00 <CIA-8> 03koen 07org.openembedded.dev * rdecc2032... 10/packages/xserver/ (2 files in 2 dirs): packages/xserver/xserver-kdrive_20050624.bb: add serial patch from #340
Sep 22 13:07:03 <CIA-8> 03jbowler 07org.openembedded.dev * r71128e6c... 10/packages/ (4 files in 3 dirs): 
Sep 22 13:07:05 <CIA-8> ucslugc, openslug-init: changes to ensure compatibility with new thumb compilation
Sep 22 13:07:07 <CIA-8> Some package builds removed from ucslugc because they are not compatible
Sep 22 13:07:09 <CIA-8> with the thumb build. openslug-init changed to use the target chroot, not the
Sep 22 13:07:11 <CIA-8> initrd one, because this actually works when the initrd and target are
Sep 22 13:07:13 <CIA-8> different operating systems.
Sep 22 13:11:35 <CIA-8> 03jbowler 07org.openembedded.dev * rdcfd3843... 10/packages/linux/ (nslu2-kernel/2.6/thumb-swi.patch nslu2-kernel_2.6.12.2.bb): nslu2-kernel_2.6.12.2: add a patch for thumb breakpoints (via a thumb SWI)
Sep 22 13:11:38 <CIA-8> 03jbowler 07org.openembedded.dev * rba30bfad... 10/packages/gdb/ (gdb-6.3/thumb-breakpoint.patch gdb_6.3.bb): 
Sep 22 13:11:38 <CIA-8> gdb_6.3: patch the thumb handling to use a thumb swi (not an undefined instr)
Sep 22 13:11:38 <CIA-8> This doesn't fix thumb debugging (a thumb program run under gdb will crash
Sep 22 13:11:38 <CIA-8> right at the start) but it does avoid the illegal instruction crash by
Sep 22 13:11:38 <CIA-8> inserting a swi instead.
Sep 22 13:26:27 <CIA-8> 03koen 07org.openembedded.dev * r3918e04d... 10/packages/netbase/netbase/interfaces: 
Sep 22 13:26:27 <CIA-8> packages/netbase/netbase/interfaces: indent usb0 entry to make
Sep 22 13:26:27 <CIA-8> sure broken apps can still read it
Sep 22 13:55:11 <cheef_daniel> why is there no modversions.h on the NSLU2?
Sep 22 13:58:25 <cheef_daniel> it should be in sys-include/linux directory
Sep 22 14:01:21 <CIA-8> 03jbowler 07org.openembedded.dev * r8982ebf1... 10/packages/meta/ (ucslugc-native.bb ucslugc-packages.bb): 
Sep 22 14:01:21 <CIA-8> ucslugc-packages: temporarily remove perl
Sep 22 14:01:21 <CIA-8> The .so link of libperl doesn't link with anything which provides the
Sep 22 14:01:21 <CIA-8> _call_via_rX functions, so it breaks on thumb (the previous version didn't
Sep 22 14:01:21 <CIA-8> work because it pulled _call_via_rX from libgcc_s.so.1 - and that doesn't
Sep 22 14:01:22 <CIA-8> always work.)
Sep 22 15:21:30 <CIA-8> 03ph5 07org.openembedded.dev * ra60d3fd5... 10/packages/pmount/ (files/mmc-fix.patch pmount_0.9.4.bb): pmount: fix pmount to work with mmc block devices
Sep 22 16:28:47 <dwery> NAiL: ping
Sep 22 16:28:53 <NAiL> pong
Sep 22 16:28:58 <dwery> NAiL: any news??
Sep 22 16:29:27 <NAiL> I was supposed to make serial cable and stuff, yes... Haven't gotten that far yet. Let me heat up my soldering iron first ;)
Sep 22 16:29:32 <NAiL> I'll start compiling
Sep 22 16:30:59 <dwery> :)
Sep 22 16:31:01 <dwery> thanks
Sep 22 16:31:59 <NAiL> now, which kernel and what patch set?
Sep 22 16:34:51 <dwery> 2.6.13.1
Sep 22 16:35:04 <dwery> the patchset is attached to my email to the list
Sep 22 16:54:05 <NAiL> ah,
Sep 22 16:54:12 <NAiL> I need more than just the stock kernel
Sep 22 17:09:36 <dwery> yep
Sep 22 17:09:49 <dwery> but the patch should apply cleanly
Sep 22 17:10:09 <dwery> (don't apply the little endian patches :) )
Sep 22 17:33:27 <cheef_daniel> why has unslung no modversions.h?
Sep 22 17:40:39 <dwery> NAiL: I have to go.. any question?
Sep 22 17:41:20 <CIA-8> 03jbowler 07org.openembedded.dev * r68ad0414... 10/packages/meta/ucslugc-packages.bb: 
Sep 22 17:41:20 <CIA-8> ucslugc-packages: remove (temporarily) sane-backends and streamripper
Sep 22 17:41:20 <CIA-8> These packages have unsatisfied thumb libgcc references as a result of
Sep 22 17:41:20 <CIA-8> recent changes.
Sep 22 17:45:56 <NAiL> dwery: no, it's getting too late for me, I'll have to continue tomorrow
Sep 22 17:46:05 <dwery> ok... see ya
Sep 22 17:46:11 <NAiL> nite
Sep 22 18:06:20 <CIA-8> 03jbowler 07org.openembedded.dev * r16278bda... 10/packages/linux/nslu2-kernel/2.6/ (13 files): nslu2-kernel: working copies of patches to push upstream
Sep 22 18:43:32 <bullet> you guys don't sleep a lot, eh? ;)
Sep 22 18:44:33 <NAiL> hehe
Sep 22 18:44:45 <NAiL> I've got a bad reputation when it comes to sleep ;)
Sep 22 18:45:05 <NAiL> my PC is too close to my bed
Sep 22 18:45:22 <NAiL> not to say that it's noisy, but it's too easy for me to come up with a good idea and reach out for the keyboard
Sep 22 18:45:29 <bullet> that's why i turn it off :)
Sep 22 18:45:36 <NAiL> nah
Sep 22 18:45:37 <bullet> hehe
Sep 22 18:45:54 <NAiL> switching it off forces me to wait in the morning
Sep 22 18:46:14 <NAiL> and I'll have to re-open to thirty-something browserwindows I have open at any time ;)
Sep 22 18:46:47 <bullet> :)
Sep 22 18:49:14 <NAiL> now, actually, I think today is a nice day to do an ubuntu install
Sep 22 18:49:39 <bullet> i installed ubuntu 5.10 preview a few days ago
Sep 22 18:49:49 <NAiL> ah
Sep 22 18:50:01 <NAiL> I've got 5.04 cd's an mass here
Sep 22 18:50:10 <NAiL> well
Sep 22 18:50:15 <bullet> cairo stuff seems a little slow...
Sep 22 18:50:43 <NAiL> I'm very interested in seeing how the AMD64 version performs :D
Sep 22 18:51:07 <bullet> slow! ;)
Sep 22 18:51:54 <NAiL> I really hope not ;)
Sep 22 18:52:03 <NAiL> I'm tired of sluggish operating systems now ;)
Sep 22 18:53:02 <bullet> hehe, nslu2ggish
Sep 22 18:53:18 <NAiL> hehe yeah
Sep 22 18:53:34 <NAiL> except WinXP x64 doesn't *really* run on a slug
Sep 22 18:54:02 <bullet> uh, i hope so :)
Sep 22 18:54:09 <NAiL> hehe
Sep 22 18:54:13 <NAiL> man
Sep 22 18:55:05 <NAiL> Here I am, a Microsoft certified systems engineer... How do I use my knowledge? ;)
Sep 22 18:55:32 <bullet> haha
Sep 22 18:55:43 <NAiL> It just struck me
Sep 22 18:55:54 <NAiL> I had totally forgotten that I have the cert :P
Sep 22 18:57:05 <NAiL> hmm
Sep 22 18:57:20 <NAiL> looks like I'll have to wait with the ubuntu install until tomorrow
Sep 22 18:58:45 <bullet> it won't walk away
Sep 22 18:59:37 <NAiL> I guess not 
Sep 22 22:30:28 <dwery> yawn
Sep 22 22:30:51 <dwery> |-)
Sep 22 23:31:47 <dwery> Jacmet: ping
Sep 23 00:51:26 <Jacmet> dwery: pong
Sep 23 00:51:46 <dwery> Jacmet: hi.. i've a question for you..
Sep 23 00:52:01 <dwery> yesterday I tried to remove the copy regs patch, those get_unaligned
Sep 23 00:52:17 <dwery> I then adapted the LE patch to cope with this
Sep 23 00:52:33 <dwery> but the result was that the kernel was unable to parse the redboot partition table
Sep 23 00:52:58 <dwery> I was wondering if the problem is the get_unaligned, something LE related or a combination of the tows
Sep 23 00:53:00 <dwery> twos.
Sep 23 00:53:48 <Jacmet> dwery: hmm, try sticking in a few printk's to see what you get when you try to read the fis table
Sep 23 00:55:10 <dwery> ok. when , exactly, get_unaligned should be used? when the memory that should be read is at an odd address?
Sep 23 00:56:10 <Jacmet> dwery: yes, whenever you do an unaligned access (E.G 16bit access to an odd address)
Sep 23 00:56:10 <jbowler-away> It actually doesn't make much sense to me.
Sep 23 00:56:26 <dwery> nor to me :)
Sep 23 00:56:28 <Jacmet> dwery: but that shouldn't happen
Sep 23 00:56:41 <jbowler-away> Right, it's a bug somewhere else.
Sep 23 00:57:02 <dwery> but where? mtd? nobody else noticed that before..
Sep 23 00:57:42 <jbowler-away> No, it's futzing 'src' - so it's in the caller.
Sep 23 00:58:23 <dwery> I don;t have the core right now.. who's the caller?
Sep 23 00:58:41 <dwery> s/core/source/
Sep 23 00:58:48 <dwery> I must sleep more...
Sep 23 00:58:57 <Jacmet> I guess you can open /dev/mtdx, seek to an odd address and begin reading from there - that would generate unaligned access
Sep 23 00:59:18 <Jacmet> if I remember the code correctly - don't have it here
Sep 23 00:59:54 <dwery> Jacmet: but is perfectly legal to do that, isn't it?
Sep 23 01:00:14 <Jacmet> dwery: yeah, I guess so
Sep 23 01:00:36 <jbowler-away> No, this is happening deep inside the kernel.  All device access is in bytes.
Sep 23 01:00:58 <dwery> jbowler-away: so it must be the kernel to handle alignedness?
Sep 23 01:01:09 <Jacmet> dwery: but wait, we're doign the BYTE0/BYTE1 stuff, so that shouldn't be a problem
Sep 23 01:01:25 * dwery starting to be confused
Sep 23 01:01:27 <Jacmet> doing even
Sep 23 01:01:56 <Jacmet> dwery: start by sticking in a few printks and see what happen - then it might be clear
Sep 23 01:02:04 <dwery> Jacmet: ok
Sep 23 01:02:05 <jbowler-away> What's weird, really weird, is that it handles an odd number of bytes correctly but not an odd 'from'
Sep 23 01:02:24 <jbowler-away> map_priv_1 must be aligned, so the only interesting case is (from & 1)
Sep 23 01:02:58 <jbowler-away> Any the RedBoot partition table is aligned, completely...
Sep 23 01:04:13 <Jacmet> exactly
Sep 23 01:04:36 <jbowler-away> It may be a real bug, maybe no one else has used 16 bit flash...
Sep 23 01:04:56 <jbowler-away> The fix in there, however, is bogus.
Sep 23 01:05:25 <dwery> i will printk the address, a direct read and a get_unaligned
Sep 23 01:05:34 <Jacmet> jbowler-away: seems quite unlikely, most boards have 16bit flash
Sep 23 01:05:44 <jbowler-away> In fact, how on earth does it work?  get_unaligned does byte accesses doesn't it?
Sep 23 01:05:52 <Jacmet> dwery: sounds good
Sep 23 01:08:58 <dwery> jbowler-away: get_unaligned, if it does what i think it does, should do a word access a the even location and return the required bye
Sep 23 01:09:07 <dwery> byte.
Sep 23 01:09:22 <jbowler-away> It's an overloaded function.
Sep 23 01:09:35 <jbowler-away> (In C++ terms)
Sep 23 01:10:27 <jbowler-away> Nope - it does byte accesses:
Sep 23 01:10:28 <jbowler-away>         (__p[0] << 8 | __p[1])
Sep 23 01:11:49 <jbowler-away> So the patch is broken - I guess it works on NSLU2 because the flash supports byte access.
Sep 23 01:12:12 <jbowler-away> Or maybe the NSLU2 flash is 8 bit - I can't remember.
Sep 23 01:12:21 <rwhitby-away> is the get_unaligned required cause access to the flash is 16bits?
Sep 23 01:12:53 <jbowler-away> No, if it was the patch would break it - the API the patch hacks deals with the 16 bit access, the patch destroys it.
Sep 23 01:12:57 <rwhitby-away> I seem to remember something about unaligned and 16bit flash access, but the memory is very fuzzy
Sep 23 01:13:44 <jbowler-away> Somewhere something is resulting in a call ixp4xx_copy_from in which 'from' is odd - an odd address in the flash, that will byte rotate the result.
Sep 23 01:15:33 <Jacmet> the flash is 16bit
Sep 23 01:16:25 <dwery> so ixp4xx_copy_from is supposed to be called with only even addresses. is that documented somewhere?
Sep 23 01:16:39 <jbowler-away> Then the comment in the code is wrong...
Sep 23 01:17:15 <jbowler-away> dwery: I suspect it is meant to support odd addresses too, but they are so rare that no one has noticed the problem before.
Sep 23 01:18:19 <jbowler-away> ixp2000 does byte access throughout
Sep 23 01:19:00 <dwery> the comment documents wideness not alignedness...
Sep 23 01:20:20 <jbowler-away> The code does 8 bit wide access, and, so far as we know, it works - so the comment is wrong.
Sep 23 01:21:38 <jbowler-away> Pretty much everything else uses memcpy, so I believe copy_from should handle odd (or even) from.
Sep 23 01:21:47 <dwery> why you're saying it's doing 8 bit? I see   u16 *src = (u16 *) (map->map_priv_1 + from);
Sep 23 01:22:05 <dwery> and data= src[i]
Sep 23 01:22:23 <jbowler-away> The patched code does 8 bit access - the original was correct from that point of view.
Sep 23 01:22:28 <dwery> ok :)
Sep 23 01:23:19 <dwery> it's possible that the nslu's flash supports 8 bit wide accesses?
Sep 23 01:26:03 <jbowler-away> It seems impossible that it doesn't - unless get_unaligned is coming from something other than .../include/asm/unaligned.h
Sep 23 01:26:32 <dwery> ok. time to printk now.
Sep 23 01:35:52 <jbowler-away> Ok, I've got a new version of that patch which is, I believe, correct.
Sep 23 01:36:22 <CIA-8> 03koen 07org.openembedded.dev * r0a4c9896... 10/packages/atd/ (files/no-oknodo.patch atd_0.70.bb): packages/atd/atd_0.70.bb: apply patch from #341 to remove -oknodo from the initscript
Sep 23 01:38:31 <dwery> jbowler-away:  where can I get it?
Sep 23 01:39:47 <dwery> btw I must have problems... the kernel is unable to detect redboot ptable.. and I've reverted my patches....
Sep 23 01:40:59 <jbowler-away> The partition table detection is probably related to the other ixp4xx.c patch which swaps the partition table probes.
Sep 23 01:41:42 <dwery> that one was in...
Sep 23 01:42:17 <jbowler-away> What are you testing on?
Sep 23 01:42:23 <Jacmet> dwery: it is normally not a problem to READ 8/16/32bit from the flash (but it depends on the bus controller) - it's writing which has to be in 16bit
Sep 23 01:42:48 <dwery> jbowler-away: 2.6.13.1 on my usual system.. it always worked.. I must have touched something..
Sep 23 01:43:03 <jbowler-away> Yes, what is your usual system...
Sep 23 01:43:14 <dwery> NSLU2
Sep 23 01:43:21 <dwery> LE
Sep 23 01:43:22 <dwery> Debian
Sep 23 01:43:36 <jbowler-away> With serial presumably.
Sep 23 01:43:39 <dwery> yes
Sep 23 01:45:04 <jbowler-away> The reworked ixp4xx-copy-from patch (untested) is in monotone (packages/linux/nslu2-kernel/2.6/10-ixp...)
Sep 23 01:46:12 <CIA-8> 03jbowler 07org.openembedded.dev * r273e4fe4... 10/packages/linux/nslu2-kernel/2.6/10-ixp4xx-copy-from.patch: nslu2-kernel: reworked ixp4xx copy_from patch
Sep 23 01:50:23 <jbowler-away> dwery: are all the added files in patches now?
Sep 23 01:50:55 <dwery> jbowler-away: wait. which files?
Sep 23 01:51:20 <jbowler-away>     drivers/i2c/chips/x1205-rtc.c \
Sep 23 01:51:20 <jbowler-away>     arch/arm/mach-ixp4xx/nslu2-io.c \
Sep 23 01:51:20 <jbowler-away>     arch/arm/mach-ixp4xx/nslu2-setup.c \
Sep 23 01:51:21 <jbowler-away>     arch/arm/mach-ixp4xx/nslu2-pci.c \
Sep 23 01:51:21 <jbowler-away>     arch/arm/mach-ixp4xx/nslu2-part.c \
Sep 23 01:51:22 <jbowler-away>     include/asm-arm/arch-ixp4xx/nslu2.h \
Sep 23 01:52:12 <dwery> they're all in the archive i sent to the ml, even if in a maybe older version
Sep 23 01:54:31 <dwery> i'll start again with a plain 2.6.13.1 and repatch it.
Sep 23 01:54:57 <jbowler-away> Why 2.6.13.1?
Sep 23 01:55:03 <dwery> is the one is use
Sep 23 01:55:13 <jbowler-away> ?
Sep 23 01:55:20 <dwery> i've based my patches on 2.6.13.1
Sep 23 01:56:01 <jbowler-away> Ah, ok...  I'm trying 2.6.14-rc2
Sep 23 01:56:12 <dwery> I planned to do it later today
Sep 23 01:56:28 <dwery> does my patcheset apply without problems?
Sep 23 01:59:28 <jbowler-away> It's still downloading rc2, I'll know in a couple of minutes
Sep 23 02:01:36 <jbowler-away> The patches apply, but I get compilation errors.
Sep 23 02:01:53 <dwery> tell me...
Sep 23 02:02:34 <jbowler-away> arch/arm/mach-ixp4xx/nslu2-pci.c:35: error: `IXP4XX_GPIO_ACTIVE_LOW' undeclared (first use in this function)
Sep 23 02:02:51 <dwery> i think they change the way to setup interrupts
Sep 23 02:02:55 <dwery> there's a new function
Sep 23 02:03:20 <jbowler-away> Ah, I'll try .13...
Sep 23 02:04:36 <dwery> once redboot works again, i'll work with 14-rc2
Sep 23 02:05:19 <jbowler-away> :)  Two weeks ago I said "I'll just get this thumb libgcc working"...
Sep 23 02:05:42 <dwery> :)
Sep 23 02:05:45 <dwery> it works again,
Sep 23 02:05:53 <dwery> now I would like to check what I managed to broke :)
Sep 23 02:07:07 <dwery> could It be that i had removed the td shutdown code?
Sep 23 02:07:10 <dwery> mtd
Sep 23 02:08:12 <jbowler-away> mtd-shutdown.patch?  That should have any effect (in fact I have it removed in the build I am going to try).
Sep 23 02:08:23 <jbowler-away> shouldn't
Sep 23 02:08:54 <dwery> mmm.. I don't knwo then.
Sep 23 02:18:13 <jbowler-away> Ok, my 2.6.13.2 build completed fine, but it used the 2.6.11.2 .config so I need to fix that...
Sep 23 02:21:21 <dwery> ok. i'm now building with printk in copy_from
Sep 23 02:21:39 <jbowler-away> reboot=s needs to go from the command line options
Sep 23 02:22:28 <dwery> is it in my patchset?
Sep 23 02:23:46 <jbowler-away> It's in the openslug (etc) configuration files in OE.
Sep 23 02:24:20 <jbowler-away> No it isn't...  I wonder where I put it.
Sep 23 02:25:17 <dwery> is the syntax modulename.moduleoption in CMDLINE still current?
Sep 23 02:28:24 <jbowler-away> I've never used that, but I would guess it hasn't changed.
Sep 23 02:32:49 <dwery> Searching for RedBoot partition table in IXP4XX-Flash.0 at offset 0x7e0000
Sep 23 02:32:49 <dwery> copy_from: [E] 7e0000
Sep 23 02:32:49 <dwery> 6 RedBoot partitions found on MTD device IXP4XX-Flash.0
Sep 23 02:32:58 <dwery> there is only one copy_from call
Sep 23 02:33:03 <dwery> and the address i seven.
Sep 23 02:33:07 <dwery> now what?
Sep 23 02:34:00 <jbowler-away> Well, the ixp4xx_copy_from code is clearly optimistic at best, and the patch I committed should be acceptable to the maintainers - it's clearly more right than the original.
Sep 23 02:34:29 <dwery> i haven;t yet seen you patch, don't know how to handle monotone :)
Sep 23 02:34:34 <dwery> anyway
Sep 23 02:34:39 <dwery> if the address is even
Sep 23 02:34:48 <dwery> why the patch is needed?
Sep 23 02:35:15 <jbowler-away> why should it be even?  It's apparently just a memcpy.
Sep 23 02:35:45 <dwery> 7e0000 isn't even?
Sep 23 02:37:10 <jbowler-away> That's only one address and one call.
Sep 23 02:37:49 <jbowler-away> Oh, and reading single bytes from /dev/mtd? certainly used to be broken...
Sep 23 02:39:04 <dwery> yes, but it's the call the kernel does to read the ptable. so at least this one seems to work fine. now, if I remove those get_unaligned, it should work too, isn't it?
Sep 23 02:39:48 <jbowler-away> Yes, that one will work.
Sep 23 02:48:30 <jbowler-away> Hum:
Sep 23 02:48:32 <jbowler-away> | /home/work-tmp/jbowler/nslu2/ucslugc/work/ixp425-eth-1.1-r8/ixp425_eth.c: In function `dev_skb_enqueue':
Sep 23 02:48:32 <jbowler-away> | /home/work-tmp/jbowler/nslu2/ucslugc/work/ixp425-eth-1.1-r8/ixp425_eth.c:662: error: structure has no member named `security'
Sep 23 02:49:44 <jbowler-away> That's going to be inconvenient.
Sep 23 02:50:09 <dwery> dunno.. i don;'t have that driver :)
Sep 23 02:51:24 <jbowler-away> This is going to take some work.... something for tomorrow I think.
Sep 23 02:54:48 <dwery> confirmed, works even without get_aligned.
Sep 23 02:55:31 <dwery> now, how do I check that everything really works?
Sep 23 02:55:42 <dwery> something like a cat or dd on .dev.mtdX?
Sep 23 02:57:05 <jbowler-away> Well, the code has a bug, so the chances are there is something to provoke it.  Trace back up in the mtd software to find how it is called...
Sep 23 02:57:32 <jbowler-away> egrep is a powerful debugging tool
Sep 23 02:58:10 <dwery> I mean.. if I read the mtd device with dd at an unaligned address, i shoul provoke the bug, isn't it?
**** ENDING LOGGING AT Fri Sep 23 02:59:56 2005