**** BEGIN LOGGING AT Fri Jan 25 02:59:59 2013
Jan 25 05:01:28 <builder_> build #167 of at91 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/at91/builds/167
Jan 25 05:33:08 <builder_> build #162 of orion is complete: Failure [failed compile_8]  Build details are at http://buildbot.openwrt.org:8010/builders/orion/builds/162
Jan 25 05:51:22 <builder_> build #136 of ixp4xx is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/ixp4xx/builds/136
Jan 25 08:05:15 <builder_> build #125 of iop32x is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/iop32x/builds/125
Jan 25 08:37:01 <builder_> build #144 of avr32 is complete: Failure [failed shell_14]  Build details are at http://buildbot.openwrt.org:8010/builders/avr32/builds/144
Jan 25 08:41:13 <builder_> build #122 of gemini is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/gemini/builds/122
Jan 25 10:28:06 <builder_> build #146 of ar7 is complete: Failure [failed shell_14]  Build details are at http://buildbot.openwrt.org:8010/builders/ar7/builds/146
Jan 25 15:13:46 <DonkeyHotei> blogic: this says you were going to commit: http://patchwork.openwrt.org/patch/3188/ just making sure it doesn't get lost in the ML.
Jan 25 16:00:53 <builder_> build #113 of octeon is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/octeon/builds/113
Jan 25 16:24:24 <builder_> build #124 of mcs814x is complete: Failure [failed shell_14]  Build details are at http://buildbot.openwrt.org:8010/builders/mcs814x/builds/124
Jan 25 18:46:47 <builder_> build #128 of adm5120 is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/adm5120/builds/128
Jan 25 19:41:58 <Pteridium> Is the SPI in the BCM63xx platform operative?
Jan 25 20:19:43 <[florian]> Pteridium: yes it is
Jan 25 20:32:46 <Pteridium> A lot of thanks
Jan 25 20:34:35 <Pteridium> Tried with mtune=4kc with BCM63xx and performs a little better, but it could be marginal
Jan 25 20:35:08 <[florian]> it's certainly very marginal
Jan 25 20:35:53 <Pteridium> The solution would be GCC patches
Jan 25 20:36:13 <Pteridium> but it's a lot of job
Jan 25 20:36:47 <Pteridium> patches for the BMIPS cores
Jan 25 20:37:06 <danitool> based on what?
Jan 25 20:37:08 <danitool> :P
Jan 25 20:37:51 <Pteridium> in order to optimize BCM63xx
Jan 25 20:38:26 <danitool> yes, but using some source code from broadcom in their toolchains...?
Jan 25 20:38:49 <Pteridium> no, the openwrt GCC
Jan 25 20:39:23 <Pteridium> but other toolchain can be used
Jan 25 20:39:53 <Pteridium> Florian: a lot of thanks
Jan 25 20:40:01 <danitool> but gcc does not contain any optimization for bmips cores doesn't it?
Jan 25 20:40:48 <Pteridium> maybe the toolchain in Broadcom sources is optimized for BMIPS cores
Jan 25 20:41:56 <Pteridium> or maybe not
Jan 25 20:42:00 <Pteridium> xDç
Jan 25 20:42:19 <danitool> probably not, why to bother with extra job...
Jan 25 20:43:34 <Pteridium> it's an idea, but is a lot of job for marginal improvements
Jan 25 20:43:45 <Pteridium> bad idea
Jan 25 20:43:47 <[florian]> no it's not optimized
Jan 25 20:44:01 <[florian]> it just contains some header file containing macros to use bmips edsp instructions
Jan 25 20:44:03 <Pteridium> ok, dead end
Jan 25 20:44:04 <[florian]> but that's all
Jan 25 20:44:24 <[florian]> we are really talking about useless micro-optimization here imho
Jan 25 20:44:33 <[florian]> the CPU scheduling is not different from a genuine mips32r1 core
Jan 25 20:44:51 <[florian]> only the ALU is know to be different because of the addition of eDSP instructions
Jan 25 20:45:29 <Pteridium> but this dsp can't be used
Jan 25 20:46:17 <Pteridium> that's a pity
Jan 25 20:46:26 <[florian]> it can be used, and it actually is used when you use the proprietary bcm63xx firmware
Jan 25 20:46:39 <[florian]> they use these instructions for the telephony firmware running on the second hardware thread
Jan 25 20:47:24 <[florian]> this is not a dedicated dsp, these are dsp instructions built into the cpu
Jan 25 20:47:36 <[florian]> pretty much like addu, subu etc .. and usable as-is
Jan 25 20:49:23 <Pteridium> then teh implementation of them would be a lot of job for "nothing"
Jan 25 20:49:30 <Pteridium> the*
Jan 25 20:50:08 <[florian]> not really, it's pretty easy to teach binutils about these new instructions so you can actually use them with their real name
Jan 25 20:50:25 <[florian]> but even simpler is using asm volatile (.word <instruction in hex format> ...)
Jan 25 20:50:35 <[florian]> which is what broadcom does with their toolchain
Jan 25 20:51:05 <Pteridium> "keep it simple"
Jan 25 20:51:14 <Pteridium> more or less
Jan 25 20:51:35 <[florian]> yep, the downside is that you can't have the assembler validate instruction constraints for your
Jan 25 20:53:12 <Pteridium> then is not the best way to use this instructions?
Jan 25 20:53:56 <Pteridium> sorry, but i'm not a programmer
Jan 25 20:54:15 <Pteridium> learned something reading your code
Jan 25 20:54:40 <Pteridium> and the patches
Jan 25 20:54:55 <Chocks> and now you are a programmer! welcome to the club.
Jan 25 20:56:30 <Pteridium> sadly not programmer, but thanks to the job of the developers i've learned a bit
Jan 25 20:56:44 <[florian]> Pteridium: well, in any case, if you want to use these dsp instructions, you really have to the need to optimize your code
Jan 25 20:56:45 <Pteridium> Noltari helped me too
Jan 25 20:56:49 <Chocks> anyone reading patches is close enough
Jan 25 20:56:55 <[florian]> which is definitively the case when you are writing a voice echo canceler for instance
Jan 25 20:57:15 <[florian]> so at specific places in your code, you will use the assembly version of these instructions to perform certain things
Jan 25 20:58:10 <Pteridium> my idea is to make this cores perform the best they can
Jan 25 20:58:45 <Pteridium> but with the default openwrt toolchain they perform very well
Jan 25 20:59:28 <danitool> better when SMP enabled in the close future..
Jan 25 20:59:59 <Pteridium> a BCM6328 outperformed a Lantiq Danube by a little margin
Jan 25 21:00:42 <Pteridium> and Danube uses A 24KEc core,
Jan 25 21:01:31 <Pteridium> Broadcom made a good job, or Lantiq made a bad job
Jan 25 21:04:52 <Pteridium> Florian: https://dev.openwrt.org.cn/browser/trunk/target/linux/brcm63x8/files-2.6.30/arch/mips/bcm963xx/smp-brcm.c
Jan 25 21:05:22 <Pteridium> I don't know if it could be helpfull
Jan 25 21:14:51 <KanjiMonster> Pteridium: that part is already in the upstream kernel (in a bit more generic way for bmips4350/4380/5000), what's missing is affinity support for the interrupt controller
Jan 25 21:16:48 <Pteridium> Noltari told me that you are having some problems with the interrupts in order to enable SMP
Jan 25 21:17:15 <KanjiMonster> Pteridium: it's not a problem, it's just missing code
Jan 25 21:17:37 <Pteridium> ¿missing code?
Jan 25 21:18:50 <KanjiMonster> the irq-code in linux only knows of the interrupt registers for the first cpu; so enabling smp currently has all interrupts fixed to the first cpu (software irqs are handled on boths cpus, as well as any threads can run on both)
Jan 25 21:18:53 <Pteridium> broadcom haven't published source code for the SMP implementation?
Jan 25 21:19:05 <KanjiMonster> they have, but the smp code isn't usable as-is
Jan 25 21:19:36 <KanjiMonster> the upstream bcm63xx code looks quite different, and has been rewritten so you can compile it to support more than bcm63xx chip at a time
Jan 25 21:20:07 <KanjiMonster> with the broadcom code you have to decide for which chip you compile
Jan 25 21:20:29 <Pteridium> yes
Jan 25 21:21:04 <KanjiMonster> and that's a no-go for openwrt
Jan 25 21:21:11 <KanjiMonster> or upstream linux
Jan 25 21:22:04 <Pteridium> But in the kernel you can decide the target SoC, no?
Jan 25 21:23:55 <KanjiMonster> we want a kernel that can run on all SoCs
Jan 25 21:24:01 <KanjiMonster> not only the one you selected
Jan 25 21:24:54 <Pteridium> ok, i understand
Jan 25 21:25:01 <Pteridium> now
Jan 25 21:25:30 <Pteridium> it's a hard job
Jan 25 21:26:18 <Pteridium> and Broadcom don't help in it
Jan 25 21:26:24 <Pteridium> sadly
Jan 25 21:26:45 <KanjiMonster> broadcom does help a bit, the upstream smp code is from broadcom (but it's from a different devision)
Jan 25 21:27:15 <Pteridium> ok
Jan 25 21:28:16 <Pteridium> i thought that Broadcom don't help to port its code
Jan 25 21:28:34 <Pteridium> sorry for my english
Jan 25 21:32:13 <Pteridium> and a lot of thanks for the enormous job of the OpenWRT people
Jan 25 21:34:09 <Pteridium> I've learned a lot about embedded systems thanks to this great team.
Jan 25 21:36:08 <Pteridium> sadly i can't help you, but i've made comments in some tickets in order to help
Jan 25 21:36:39 <Pteridium> in example: https://dev.openwrt.org/ticket/12872
Jan 25 21:37:09 <Pteridium> little help, but better than nothing
Jan 26 01:45:42 <builder_> build #167 of brcm47xx is complete: Success [build successful]  Build details are at http://buildbot.openwrt.org:8010/builders/brcm47xx/builds/167
Jan 26 01:49:09 <builder_> build #151 of rb532 is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/rb532/builds/151
Jan 26 01:52:32 <builder_> build #151 of ppc44x is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/ppc44x/builds/151
Jan 26 02:28:43 <builder_> build #156 of uml is complete: Failure [failed compile_4]  Build details are at http://buildbot.openwrt.org:8010/builders/uml/builds/156
Jan 26 02:53:51 <builder_> build #141 of sibyte is complete: Failure [failed shell_12]  Build details are at http://buildbot.openwrt.org:8010/builders/sibyte/builds/141
**** ENDING LOGGING AT Sat Jan 26 02:59:59 2013