**** BEGIN LOGGING AT Tue Oct 03 02:59:57 2006 Oct 03 03:08:22 03dyoung * r4165 10optware/trunk/make/imap.mk: update the archive location Oct 03 04:16:45 03dyoung * r4166 10optware/trunk/make/libnsl.mk: Added ts72xx arch Oct 03 06:20:07 03dyoung * r4167 10optware/trunk/make/noip.mk: update the source version Oct 03 08:18:15 Hi, can anybody help me with building openslug-image from the master makefile? Oct 03 10:49:21 03dyoung * r4168 10optware/trunk/Makefile: Completed the list of TS72xx broken packages, does complete build now. Oct 03 11:38:51 03dyoung * r4169 10optware/trunk/sources/ts72xx-bootstrap/bootstrap.sh: Oops, change the name to the right target. Oct 03 15:49:17 Has any reference to Intel's ixp-osal library already been removed from .dev? I get a compile error on ixp-osal. Oct 03 15:52:19 yes Oct 03 15:52:27 (or, atleast I think so) Oct 03 15:52:31 what error are you getting? Oct 03 15:52:43 why are you building it? Oct 03 15:53:24 and have you built only the 2.6.17 (not 2.6.18) kernel, if you are? Oct 03 15:54:13 | Makefile:381: target `lib/ixp425/linux/linuxbe/.dirCreationFlag' given more than once in the same rule. Oct 03 15:54:15 | Makefile:452: lib/ixp425/linux/linuxbe/src/platforms/ixp400/IxOsalIxp400.d: No such file or directory Oct 03 15:54:35 2.6.18.. Oct 03 15:54:51 well then build 2.6.17, it is broken on 2.6.18 Oct 03 15:55:06 going back to the first question, why are you building it? Oct 03 15:56:25 blaster8: because it works. Oct 03 15:56:36 aah, that's where you're wrong Oct 03 15:56:52 blaster8: you mean because of the crappy license? Oct 03 15:57:01 no, it is an appalling piece of code Oct 03 15:57:16 which needs to be fixed to work with practically every new kernel releas Oct 03 15:57:30 use the open driver if you're building HEAD, because that is all that we're supporting Oct 03 15:58:25 blaster8: ok, but I tend to make changes step-by-step :-) Oct 03 15:58:38 ok, 2.6.18 includes the open driver Oct 03 15:59:05 if you want to use our 2.6.18, you will find yourself building and using the open driver without any other steps Oct 03 15:59:20 just don't build the intel driver, and add ixp4xx-npe to your image Oct 03 15:59:33 are you running BE? Oct 03 15:59:38 blaster8: yes Oct 03 15:59:45 good Oct 03 16:00:05 then the open driver is pretty solid, to be honest Oct 03 16:02:05 blaster8: HEAD now also runs on our custom board. Nice. It's only that the IXP4xx Ball Grid Array is badly soldered, and we have a bad contact somewhere to SDRAM on one of the prototypes I was debugging... Oct 03 16:02:26 ? Oct 03 16:02:39 ok, do you use the ixdp setup for your custom board? Oct 03 16:02:47 i.e. does it have its own machine id? Oct 03 16:04:17 blaster8: yes, the board is only slightly different from the IXDP425 in terms of Flash, SDRAM and Ethernet. Oct 03 16:04:41 blaster8: machine ID about to be registered, but currently we test with decimal 444 (to make sure it is different) Oct 03 16:04:48 how many ethernets? Oct 03 16:05:23 2 Oct 03 16:05:44 so, PHY 0 connected to NPE-B and PHY 1 connected to NPE-C then Oct 03 16:06:05 so the mac setup routine in ixdp-setup.c should work fine for your board Oct 03 16:06:16 which means you're good to go with the open source driver Oct 03 16:06:18 On one proto PHY 0=B, PHY 15(fifteen)=C, on a second proto PHY 0=B, PHY 1=C Oct 03 16:06:36 ok, simpler to just use 0/1 Oct 03 16:06:53 but it's just a one-line change in *-setup.c Oct 03 16:07:14 blaster8: we have some serious workarounds for the PCI errata of the IXP4xx, so there are lots of kernel patches. Oct 03 16:07:40 are they not in the mainline kernel? Oct 03 16:07:40 no Oct 03 16:07:45 how many PCI devices? Oct 03 16:07:46 blaster8: because you *need* a hardware workaround as well, controlled by two GPO lines. Oct 03 16:07:51 one PCI dev. Oct 03 16:08:26 oh sheesh Oct 03 16:08:59 blaster8: yes... The IXP4xx fails on writing 16-bit words, memory-mapped, on PCI. (It fails to steer the byte enables) Oct 03 16:09:19 blaster8: most PCI devices have 32-bit registers, but we have one ASIC that has 16-bit regs... Oct 03 16:09:27 aah Oct 03 16:09:28 ok Oct 03 16:10:13 blaster: Intel released this info right after our first two proto runs were complete.... Oct 03 16:10:18 classic Oct 03 16:10:22 got to love Intel Oct 03 16:10:25 yes. Oct 03 16:10:56 Freescale Coldfire MCF5475 is a competative chip, I think, no firmware blobs needed :-) Oct 03 16:11:48 Probably the IXP465 is fixed, but still needs the NPE firmware. Oct 03 16:11:49 what bootloader do you use? Oct 03 16:12:22 blaster8: currently RedBoot, but I think using/porting the new open-source driver to u-boot would be cool. Oct 03 16:12:48 APEX is also quite useful Oct 03 16:12:52 Maybe APEX. We have not decided yet. Oct 03 16:12:56 ah :-) Oct 03 16:13:24 We also want to use the same bootloader for the TI ARM DaVinci DSP/ARM combo and the Cirrus ARM EP93xx Oct 03 16:13:25 The dev is keen to get ethernet support with the IXP425, which is something Oct 03 16:13:42 issues, then Oct 03 16:14:51 anyway, need to get on, glad to hear that HEAD works on an ixdp425-like machine Oct 03 16:14:57 good luck Oct 03 16:16:11 thanks for the help again Oct 03 17:30:13 whould like to think about better initscripts for optware, but don't know the debian way so well, would it be a problem to do it like red hat ... ? Oct 03 18:19:44 I've got no idea how redhat does it Oct 03 18:43:11 NAiL: use links from /etc/init.d/script to /etc/rc3.d/SXXscript, configured by a command chkconfig, of course we wouldn't need the runlevels Oct 03 18:44:15 NAiL: initscripts sources config files from /etc/sysconfig/configfile Oct 03 18:45:22 I want to be able to disable a service without removing the ipk or manipulating the initscript itself Oct 03 18:47:03 not sure, but I believe the difference to debian is that the command for manipulating the initscripts is update-rc.d or so, with a strange syntax, at least for me Oct 03 19:18:42 Tobbe: An ipkg update ; ipkg upgrade coreutils should now get you a version with a working df Oct 03 19:44:09 AdamBaker: Yeah, I saw it a few hours ago. Thanks man Oct 03 19:56:54 AdamBaker: the new coreutils is broken on wl500g right now Oct 03 20:01:42 03bzhou * r4174 10optware/trunk/make/py-scgi.mk: py-scgi: upstream upgrade to 1.12 Oct 03 20:22:23 good day Oct 03 20:22:50 anybody ever built the latest ov511 drivers under OE? Oct 03 20:23:01 I know they are built-in the kernel but those are extremely old Oct 03 20:58:11 eno-away: sorry, what's the problem with it? Oct 03 21:10:29 AdamBaker, I'm basically trying to create an OE package for the updated ov511 tarball. Oct 03 21:11:01 I tried cloning the pwc setup but didn't work. Oct 03 21:11:40 What does OE use to make modules? the External makefile method or the new linux kernel sub-dir method??? Oct 03 21:15:15 AdamBaker, sorry. wrong thread. Oct 03 21:53:15 03aabaker * r4175 10optware/trunk/make/coreutils.mk: coreutils: attempt to fix build error on wl500g Oct 03 22:02:51 03bzhou * r4176 10optware/trunk/make/coreutils.mk: coreutils: fix LDFLAGS for wl500g Oct 03 22:03:17 AdamBaker: coreutils at least builds on my local env for wl500g Oct 03 22:03:33 i don't have wl500g so i cannot do runtime test Oct 03 22:14:40 I don't have an wl500g either but I've just built the wl500g ipk and installed it on my WAG354G and it seems to work on that - My build env isn't quite the same as the official wl500g one so I never fully trust my builds though. Oct 03 22:20:26 If someone is sufficiently motivated, there are a handful of packages with missing sources: rdate sane-backends syslog-ng squeak tethereal webalizer Oct 03 22:20:50 I fixed the handful of easy ones already, those are whats left. Oct 03 23:05:47 03bzhou * r4177 10optware/trunk/make/tethereal.mk: tethereal: update source URL Oct 03 23:33:08 lol, shall we set rdate source to http://ftp.osuosl.org/pub/nslu2/sources/rdate-1.4.tar.gz ? Oct 03 23:33:33 kind of recursive Oct 03 23:34:21 if that's the only stable place we can find it, yes. Oct 03 23:34:54 but I would use http://sources.nslu2-linux.org/... instead Oct 03 23:35:24 (in case we ever need to move away from osuosl for some unforseen reason) Oct 03 23:36:23 good point, i cannot find any other stable source for it now Oct 04 00:42:57 03bzhou * r4178 10optware/trunk/make/noip.mk: noip: workaround the lack of versioning with noip source tarball Oct 04 01:16:54 heh heh Oct 04 01:17:07 I knew if I put it out there someone sufficiently motivated would help. ;-) Oct 04 01:34:45 03dyoung * r4179 10optware/trunk/Makefile: Add stuff to the TS72xx no-build list Oct 04 01:36:50 03bzhou * r4180 10optware/trunk/make/git-core.mk: git: upstream upgrade to 1.4.2.3 Oct 04 01:37:19 03bzhou * r4181 10optware/trunk/make/cogito.mk: cogito: upstream upgrade to 0.18 Oct 04 01:45:43 03bzhou * r4182 10optware/trunk/make/webalizer.mk: webalizer: change to a working SITE Oct 04 01:49:29 03bzhou * r4183 10optware/trunk/make/syslog-ng.mk: syslog-ng: changed to a working SITE Oct 04 02:19:41 03dyoung * r4184 10optware/trunk/make/bsdmainutils.mk: update the source version Oct 04 02:35:30 03placid * r4185 10optware/trunk/make/libupnp.mk: libupnp: upstream to newly maintained pupnp 1.4.1 Oct 04 02:54:41 has anyone considered piping the actual build details into separate files to keep the size of the log under control? The current log is 55MB and is very hard to read due to the sheer size. Linking to the individual build files would make the main log easier to read as well. Oct 04 02:57:31 does anyone have any opinion on it for that matter :) **** ENDING LOGGING AT Wed Oct 04 02:59:57 2006