**** BEGIN LOGGING AT Mon Apr 26 02:59:56 2010 Apr 26 04:06:49 abyrne * r21161 /packages/ipv6/wide-dhcpv6/ (Makefile files/dhcp6c-state files/dhcp6c.conf): [packages] wide-dhcpv6: Fix request option variable names Apr 26 09:22:25 florian * r21162 /trunk/target/linux/brcm63xx/ (patches-2.6.32/240-spi.patch patches-2.6.33/240-spi.patch): [brcm63xx] the SPI_CMD register is 16-bits wide Apr 26 09:22:29 florian * r21163 /trunk/target/linux/brcm63xx/ (3 files in 2 dirs): [brcm63xx] fix bcm6358 spi base register address (#7234) Apr 26 10:38:30 hum what's that? Apr 26 10:40:21 oh, 6358 base address is unset, i did notice that yesterday :) Apr 26 11:13:00 <[florian]> ali1234: yes it was unset Apr 26 11:13:19 <[florian]> ali1234: I have fixed the SPI_CMD 8-bit access, but that's all Apr 26 11:13:24 <[florian]> ali1234: it does not mean it works yet ;) Apr 26 11:32:21 hmm i got an interrupt of some sort Apr 26 11:32:43 well, i got a change in the INT_STATUS Apr 26 11:32:52 no actual interrupt for the handler though Apr 26 11:38:06 hmm actually that makes me think Apr 26 11:38:14 maybe i'm looking in the wrong place Apr 26 11:45:54 <[florian]> well, I do not think so Apr 26 11:46:03 <[florian]> but I begin to wonder if the spi core can actually generate interrupts at all :) Apr 26 11:46:09 <[florian]> maybe it works in polling mode only Apr 26 11:48:15 well here's the thing Apr 26 11:48:22 i set the mask register to 0 Apr 26 11:48:32 then stuff starts showing up in the status register Apr 26 11:49:07 it's as if when interrupts are enabled, something catches it and clears the register... something other than the handler though Apr 26 11:49:50 its especially stange as it shows up in the status, not the masked_status Apr 26 11:50:05 maybe the meaning of the mask register is backwards (1 means mask it) Apr 26 11:50:40 <[florian]> maybe Apr 26 11:51:21 it does contain all 0 when in cfe mode Apr 26 11:51:48 <[florian]> still you should be able to enter the driver interrupt handler Apr 26 11:51:58 <[florian]> we can try to get it working with interrupts disabled first Apr 26 11:52:14 ali1234: well, you could fiddle a bit to set the spi core to a non-shared irq and catch it directly to see what happens Apr 26 11:52:33 i never had it generate an actual IRQ Apr 26 11:52:48 i just got it to update the status register Apr 26 11:53:33 i will keep messing with the registers to tr to work out what is happening... Apr 26 11:54:00 hmm Apr 26 11:54:06 ali1234: did you check, if it has a vaild irq setting on startup? Apr 26 11:54:09 a LOT of interrupts Apr 26 11:54:28 well it definitely can generate them then :) Apr 26 11:55:10 i wrote CMD_NOOP to the command register and it went crazy Apr 26 11:55:56 that's not a good sign Apr 26 11:56:04 sure it is Apr 26 11:56:09 <[florian]> the core might be buggy under certain circumstances Apr 26 11:56:22 i wrote it with devmem Apr 26 11:56:34 <[florian]> ah ah :) Apr 26 11:57:05 anyway, i got a lot of CMD_DONE interrupts as a result Apr 26 11:58:01 ah it's the handler, it doesn't clear the status register Apr 26 11:58:04 <[florian]> and you are entering the driver interrupt handler? Apr 26 11:58:08 yes Apr 26 11:58:15 <[florian]> then most likely I inverted the status/mask register Apr 26 11:58:20 nope Apr 26 11:58:23 <[florian]> because the first thing it does it trying to clear them Apr 26 11:58:48 yeah but there is a bug Apr 26 11:59:03 you are doing the clear op on INT_MASK instead INT_STATUS Apr 26 11:59:17 so instead of clearing you are unmasking then :) Apr 26 12:02:45 better Apr 26 12:02:50 but sometimes it hangs :/ Apr 26 12:03:03 but sometimes it gets just one interrupt like you would expect Apr 26 12:08:22 oh, the crash was a typo... Apr 26 12:08:29 so it seems to work for CMD_NOOP Apr 26 12:14:46 CMD_SOFT_RESET also generates interrupt Apr 26 12:15:25 and CMD_SOFT_RESET|CMD_NOOP generate CMD_DONE|CMD_BUSY Apr 26 12:15:54 no wait, CMD_DONE|TX_UNDERFLOW hmm Apr 26 12:16:33 <[florian]> because there is nothing in the fifo at that time I assume Apr 26 12:16:58 well, sending two commands OR'd does not make sense Apr 26 12:17:07 but if it said "busy" that would kind of make sense Apr 26 12:17:30 but, sending START_IMMEDIATE does not generate any interrupt Apr 26 12:18:13 it doesn't mess up the state machine though, another NOOP works OK Apr 26 12:28:01 hi Apr 26 12:29:21 anyone able to offer some advice related to my attempts to build a kernel for an arm/orion5x device? Apr 26 12:30:49 it is a DNS-323 and uses u-boot bootloader Apr 26 12:31:06 (network storage box) Apr 26 12:31:15 bodksi: well, what exactly is the problem? Apr 26 12:32:32 I can get buildroot to output a kernel and with an addition to target/linux/orion/image/Makefile it gets packaged in uboot format, but freezes on "Uncompressin kernel.......done" after flashing Apr 26 12:33:10 bodksi: well, that's a more difficult problem Apr 26 12:33:23 bodksi: you have the original vendor kernel code? Apr 26 12:33:50 yes, but more relevant is that there is a kernel compiled from debian that works, so I tried to use the .config from this to build it, same thing happens Apr 26 12:34:14 I am wondering if it is a toolchain configuration problem Apr 26 12:34:23 bodksi: well, you have to play then Apr 26 12:34:59 bodksi: compile the debian kernel with the openwrt toolchain, then compile the a vanilla kernel, then start playing with the patches Apr 26 12:35:45 OK cheers, do you know which openwrt people work on orion stuff, so I can look out for them here? It seems they have probably been through similar 'hoops' to get the orion based routers up and running Apr 26 12:36:06 <[florian]> Kaloz has been working on orion Apr 26 12:36:44 ok thanks :) Apr 26 12:48:43 well this is interesting. it looks like 0x3 is a valid SPI command Apr 26 12:48:47 at least CCFE uses it Apr 26 12:50:23 http://pastebin.com/egAtELHm Apr 26 12:50:41 is there any overview over the bcm63xx system architecture? (e.g. something like the ssb on bcm47xx)? Apr 26 12:51:06 <[florian]> no, this is documented under nda Apr 26 12:51:25 <[florian]> but I can give you some hints about how it works internally Apr 26 12:51:47 <[florian]> the SoC architecture is a bit simpler than bcm47xx and does not have "core discovery" and identification like ssb has Apr 26 12:52:15 <[florian]> the various cores are memory-mapped Apr 26 12:52:33 <[florian]> and there is a DMA engin which allows you to do CPU to peripheral DMA and peripheral to peripheral DMA Apr 26 12:52:55 <[florian]> the complete SoC supports clock gating so that you can turn off parts of the SoC which are unused Apr 26 12:53:34 I see Apr 26 12:54:26 <[florian]> there is also a DSP engine for DSL Apr 26 12:55:00 <[florian]> which can be used for echo cancelling and transcoding if you use it as a voice gateway instead Apr 26 12:55:40 the voice stuff seems to be on a daugther board Apr 26 12:55:53 <[florian]> it depends on the design Apr 26 12:56:00 at least on the device I have here Apr 26 12:56:04 <[florian]> most of the time, a voice packetizer is added separately Apr 26 12:56:11 <[florian]> with slic/slac chips Apr 26 12:56:41 there's a bcm6341 Apr 26 12:56:43 on it Apr 26 12:57:03 <[florian]> that one does the DSP job because the primary dsp engine is used for DSL I assume Apr 26 12:57:18 probably Apr 26 12:58:53 since I plan to reverse engineer the broadcom binary only modules for it, its probably best if I create some documentation from it so someone else can create drivers Apr 26 12:59:20 I plan to /try/ - I don't know wether I succeed ;) Apr 26 13:04:35 hmm i note that 1<<3 = 8, maybe 3 really is the tx command and not 8 Apr 26 13:06:02 <[florian]> 3 = (1 << 1) | (1 << 0) = 2 + 1 Apr 26 13:06:29 [florian]: are there any datasheet for the dsl enginge (under a nda)? Apr 26 13:06:57 <[florian]> rtz2: under nda, yes, there is datasheet for the sar engine and the dsl AFE Apr 26 13:07:55 [florian]: i realise that, but writing "3" in the command reg returns tx_underflow like you would expect from the send command, which is 8 in regs.h Apr 26 13:08:14 [florian]: any change for open source developers to get them, or they only for clients how by hardware? Apr 26 13:08:18 chance Apr 26 13:08:51 <[florian]> rtz2: no chance, they do not care about developpers, only people that buy millions of chips Apr 26 13:08:51 also this isn't the only place where you seem to have used (1< also it doesn't make sense for either command or device ID to be a bitmask Apr 26 13:09:50 not to me anyway :) Apr 26 13:09:55 that's kinda sad Apr 26 13:10:16 [florian]: and nobody leaked a datasheet either, I assume? Apr 26 13:10:25 <[florian]> rtz2: code yes, datasheet, no Apr 26 13:10:49 what is the legal status of code based on leaked datasheets? Apr 26 13:11:29 I would guess tainted, but IANAL Apr 26 13:11:34 <[florian]> I do not think it has any kind of legal status Apr 26 13:11:45 KanjiMonster: well, the leaked code should give you a starting point Apr 26 13:12:06 <[florian]> ali1234: I think the chip-select handling is just messed up Apr 26 13:12:16 <[florian]> ali1234: there is an extraneous 1 << here Apr 26 13:12:25 yeah, that's what i mean Apr 26 13:12:39 rtz2: I mean if I create code based on a leaked datasheet, can I still put it under gpl, or is it safe to "use" publically? Apr 26 13:12:52 KanjiMonster: I doubt it's a problem Apr 26 13:12:59 well i'm going to try setting the command to 3 instead 8 and see what happens Apr 26 13:13:29 KanjiMonster: it's like writing a description of a painting Apr 26 13:13:53 <[florian]> KanjiMonster: to be frank, I do not think a reverse engineering attempt without leaked code can possibly work Apr 26 13:14:09 <[florian]> KanjiMonster: there are lots of things to know about dsl to be conformtable with it Apr 26 13:14:35 [florian]: well, the b43 wireless driver also works Apr 26 13:14:54 <[florian]> rtz2: correct it took a lot of years Apr 26 13:15:01 right Apr 26 13:15:11 [florian]: well, the kernel modules aren't stripped, so there is at least some information; also there are headers bringin in some information about the functions Apr 26 13:15:35 <[florian]> KanjiMonster: yes, but that's really the visible part :) Apr 26 13:16:00 KanjiMonster: not sure about the details, but if you create only docs from the leaked code, it may be even legal Apr 26 13:16:29 [florian]: and I can read mips32 ;) Apr 26 13:16:30 <[florian]> rtz2: that's what happened for b43 at some point Apr 26 13:16:59 KanjiMonster: I don't think it will be hard to find somebody how is willing to write a driver Apr 26 13:17:08 rtz2: I don't have any leaked code. Apr 26 13:17:18 KanjiMonster: it would be a pretty cool thing to have Apr 26 13:17:26 I just saw some atheros datasheets on a chinese website Apr 26 13:17:42 KanjiMonster: well, you either have to use google or get creative ;) Apr 26 13:19:04 and until now I stayed clear of them (one is for a switch, the other for a wireless chip) ;) Apr 26 13:22:26 [florian]: regarding dsl: yeah, I am already looking if there's a way to get the ITU documents for the g99x parts Apr 26 13:22:34 well this is new. spidev_test now seems to work, at least the first time it sends Apr 26 13:24:40 <[florian]> KanjiMonster: some are public Apr 26 13:33:50 florian * r21164 /trunk/target/linux/brcm63xx/ (patches-2.6.32/240-spi.patch patches-2.6.33/240-spi.patch): [brcm63xx] fix spi chip select configuration Apr 26 13:34:54 [florian]: i'm pretty sure that the commands are same... now the first write succeeds, and all subsequent writes return the tx_underrun. so probably just fill_tx needs fixing now Apr 26 13:35:22 <[florian]> ali1234: I guess so Apr 26 13:38:00 hmm maybe not Apr 26 13:38:10 that first success interrupt could be from the reset Apr 26 13:50:14 ah i see what's happening Apr 26 13:51:04 in spi_chipselect it reads the CMD reg, ors with chipselect, and writes back. causing the last command executed to be run again Apr 26 13:53:04 <[florian]> ah, shame on me :p Apr 26 13:53:35 but unfortunately this means it's still no closer to actually working Apr 26 13:56:22 if i'm right about the commands being 0,1,2,3 not 1,2,4,8 then it explains why NOOP doesn't raise an interrupt. you would use it when setting the chipselect etc Apr 26 13:57:24 1,2,3 and f all raise an interrupt, others do nothing Apr 26 13:57:47 and of those, they all return CMD_DONE except 3 whicch return CMD_DONE|TX_UNDERRUN Apr 26 14:41:14 <[florian]> ali1234: sounds like there is a divide by 2 error there :) Apr 26 14:41:26 how so? Apr 26 14:41:38 <[florian]> 0,1,2,3 vs 1,2,4,8 Apr 26 14:41:47 no, it's << again Apr 26 14:41:57 x = 1< where x = 1,2,4,8 and y = 0,1,2,3 Apr 26 14:42:17 <[florian]> divide, multiply depends the sense you give it Apr 26 14:42:34 <[florian]> which side of the operator, we are talking about the same thing :) Apr 26 14:42:36 is there any more recent specsheet than this http://wiki.freeswitch.org/wiki/Specsheet ? Apr 26 14:42:37 well i suppose Apr 26 14:42:45 sorry wrong channel :) Apr 26 14:42:48 but it's not divide by 2 but y :) Apr 26 14:43:08 anywhoo, i'm no closer still. need to look at some more assembly i think Apr 26 14:49:17 here is a thing. write 0xffff to command reg and read it back, you get 0x1F7F Apr 26 14:49:26 7 being where the device id seems to go Apr 26 15:21:15 wow Apr 26 15:22:00 well i got cmd 3 to return cmd_done success Apr 26 15:22:08 but then the kernel crashed Apr 26 15:22:43 http://pastebin.com/HN8NUZry Apr 26 15:26:07 it looks like i got a reply this time and that caused the rash Apr 26 15:26:11 +c Apr 26 15:32:08 hmm ok so it is getting stuk in the interrupt handler on rx now Apr 26 15:33:08 ok, it's a silly bug :) Apr 26 15:35:30 ah, and the crash was due to wildly overwriting memory in a never ending loop Apr 26 16:08:29 rhk * r21165 /packages/libs/clearsilver/Makefile: [packages] clearsilver: fix DEPENDS and simplify Makefile Apr 26 16:10:04 hmm something isn't right here Apr 26 16:10:28 by the time the spi request gets to the driver the rx and tx pointers point to the same place. this is not what spidev_test is sending in the ioctl Apr 26 16:38:26 hi Apr 26 16:39:15 nbd * r21166 /trunk/target/linux/ar71xx/files/drivers/net/ag71xx/ag71xx_main.c: ag71xx: remove rx alignment code for small packets, it seems to break ipv6 for some reason (fixes #7236) Apr 26 17:59:52 hauke * r21167 /trunk/package/mac80211/patches/700-mwl8k-missing-pci-id-for-WNR854T.patch: Apr 26 17:59:52 mac80211: add pci id for WNR854T Apr 26 17:59:52 This closes #7209 and is an addition to r21077. Apr 26 18:11:09 is transparent proxy support planned for further openwrt releases? Apr 26 18:11:45 openwrt can already do it Apr 26 18:11:58 you just need something with lots of storage and ram and then you can install squid in openwrt ;) Apr 26 18:12:36 i have haproxy Apr 26 18:13:47 it work great and tproxy support can be built, but i dont understand the requirements for the os Apr 26 18:15:37 every time i read about transparent proxy i see the page http://www.balabit.com/downloads/files/tproxy/ Apr 26 18:22:55 in the squid feature list i read : Kernel 2.6.32 is known to have a TPROXY problem. Apr 26 18:23:22 backfire is 2.6.32, so i dont think openwrt can allready do it Apr 26 18:23:41 the problem ist listed here: http://wiki.squid-cache.org/Features/Tproxy4 Apr 26 18:26:51 ok i think this thing is working now Apr 26 18:27:20 i send 38 bytes, it looks like i get 38 bytes back Apr 26 18:27:32 all 0xff though so the slave obviously isn't responding Apr 26 18:27:49 juhosg * r21168 /trunk/target/linux/ar71xx/image/Makefile: Apr 26 18:27:49 ar71xx: create separate 'factory' and 'sysupgrade' images for the WRT160NL Apr 26 18:27:49 The 'factory' image requires the garbage at the end of the image. Apr 26 18:27:49 Flashing from the original web interface does not work without that. Apr 26 18:27:53 juhosg * r21169 /trunk/target/linux/ar71xx/ (image/Makefile profiles/tp-link.mk): ar71xx: create firmware images for the TL-WR941ND v3 boards Apr 26 18:27:57 juhosg * r21170 /trunk/target/linux/ar71xx/image/Makefile: ar71xx: create smaller sysupgrade images for the WRT400N board Apr 26 18:28:01 juhosg * r21171 /trunk/target/linux/ar71xx/image/Makefile: ar71xx: build different firmware images for the DIR-825-Bx boards Apr 26 18:28:03 juhosg * r21172 /trunk/target/linux/ar71xx/files/arch/mips/ar71xx/mach-mzk-w04nu.c: ar71xx: fix firmware partition size on the MZK-W04NU board Apr 26 18:28:06 juhosg * r21173 /trunk/target/linux/ar71xx/files/arch/mips/ar71xx/mach-mzk-w300nh.c: Apr 26 18:28:06 ar71xx: remove config partition from the mtd map on the MZK-W300NH board Apr 26 18:28:06 This space can be used to extend the rootfs_data partition. Apr 26 18:28:08 <[florian]> ali1234: good job! Apr 26 18:28:09 juhosg * r21174 /trunk/tools/firmware-utils/src/mkplanexfw.c: Apr 26 18:28:09 tools/firmware-utils: add size check to the mkplanexfw tool Apr 26 18:28:09 Also pad the image to a 64K boundary. Apr 26 18:28:12 juhosg * r21175 /trunk/target/linux/ar71xx/image/Makefile: Apr 26 18:28:12 ar71xx: create separate 'factory' and 'sysupgrade' images for the Planex Apr 26 18:28:12 boards Apr 26 18:28:41 actually perhaps not, it looks like the whole rx buffer is full of 0xff not just the first 38 bytes Apr 26 18:29:20 i am confused by rx_tail, it doesn't seem to contain a meaningful value Apr 26 18:31:25 <[florian]> it should be an index in the fifo Apr 26 18:31:32 it is Apr 26 18:31:39 but it's pointing to msg tail Apr 26 18:31:57 <[florian]> ali1234: hum Apr 26 18:32:01 hmm although that would make sense, 1 byte in, one byte out Apr 26 18:32:09 the tail is same place in the rx fifo Apr 26 18:32:22 <[florian]> yes that's how spi works Apr 26 18:32:37 <[florian]> the spi core can support more complex transfers actually Apr 26 18:32:42 something has happened to the input buffer too Apr 26 18:32:54 i mean the msg buff Apr 26 18:33:10 it's been overwritten too Apr 26 18:35:52 <[florian]> it is supposed to hold the reply, so that would not surprise me Apr 26 18:36:08 what do you mean? Apr 26 18:36:16 there's two fifos, msg, and rx Apr 26 18:36:52 <[florian]> yes, but I am not sure if the msg does not point back to the rx fifo once the command has been issued Apr 26 18:37:15 hmm no, it's right Apr 26 18:37:24 msg fifo is intact Apr 26 18:37:33 response is all 0xff right up to the end Apr 26 18:37:50 <[florian]> that means the device did not answer back with valid data Apr 26 18:38:02 <[florian]> which can be either a badly formatted spi message sent over the wire Apr 26 18:38:03 oh, once again, i am wrong Apr 26 18:38:09 <[florian]> or a wrong spi chip select being asserted Apr 26 18:38:19 it was filled with 0xff up to 38 bytes, same length as message Apr 26 18:38:32 <[florian]> is not that the fill byte ? Apr 26 18:38:38 it is by default Apr 26 18:38:47 but if i change the fill byte value it still gets filled with 0xff Apr 26 18:39:05 <[florian]> ok, so that means the device did not answer correctly Apr 26 18:39:07 <[florian]> probably because "it" did not understand the command you sent in Apr 26 18:39:33 <[florian]> I have a spi logic analyzer here, so if you can send me your intermediate work I can check on the wire Apr 26 18:40:16 http://pastebin.com/rmPJeVw8 Apr 26 18:40:25 you'll have to diff it against your version Apr 26 18:40:28 there a re a lot of changes Apr 26 18:40:35 some maybe pointless :) Apr 26 18:41:39 oh and some changes in the regs.h too Apr 26 18:42:08 http://pastebin.com/ahxyjSZC Apr 26 18:42:25 i confirmed in the broadcom code, START_IMMEDIATE really should = 3 Apr 26 18:44:18 i think there are actually 8 chip select lines too Apr 26 18:45:18 hmm and another thing, i think this is still broken Apr 26 18:45:33 i have a feeling the tail pointers won't reset automatically Apr 26 18:46:12 hmm... i am wrong again Apr 26 18:46:23 writing the msg_ctl seems to reset it Apr 26 18:48:26 <[florian]> ali1234: I thought there was only 4 chip-select Apr 26 18:48:35 <[florian]> 1 being hard-wired, the 3 others being over gpios Apr 26 18:49:05 maybe Apr 26 18:49:19 the register accepts values 0-7 Apr 26 18:49:28 so three bits, any combination Apr 26 18:49:52 <[florian]> that would seem logical to me Apr 26 18:50:47 oh you need to register the spidev driver too Apr 26 18:50:56 <[florian]> of course Apr 26 18:51:21 <[florian]> if it works, more work to register spi devices will be required Apr 26 18:51:21 http://pastebin.com/062TNd3f Apr 26 18:54:12 craigc * r21176 /packages/net/multiwan/ (Makefile files/usr/bin/multiwan): [packages] multiwan: Updated failover removal Apr 26 18:55:50 hmm, well, i can't get the state to go back to rx empty Apr 26 18:56:09 reading the buffer doesn't clear it, and neither does writing into the status register Apr 26 18:57:47 hmm writing command 0xf seems to clear it out Apr 26 18:57:50 <[florian]> ali1234: do not you think I also messed up the INTR_* bits? Apr 26 18:57:58 no Apr 26 18:58:06 <[florian]> ok, only the CMD_* ones Apr 26 18:58:06 they look fine Apr 26 18:58:25 well, not sure Apr 26 18:58:43 i have only seen cmd_done for a while Apr 26 19:01:11 i think the fill register is only used in halfduplex write Apr 26 19:01:16 likewise for prepend bytes Apr 26 19:02:46 oh heres a bug Apr 26 19:02:53 #define SPI_MSG_TYPE_SHIFT 14 Apr 26 19:02:58 this should be 6 not 14 Apr 26 19:03:21 giving a max msg length of 0x3f, and the top two bits for msg type Apr 26 19:03:29 0x3f = same length as msg fifo Apr 26 19:05:24 <[florian]> yes Apr 26 19:05:40 <[florian]> so many typos, not sure what I smoke that day :p Apr 26 19:07:23 the state machine does seem to check that you write the same number of bytes as you declared in the msg ctl Apr 26 19:07:48 so i would say tx underrun after only writing 1 byte would be logical Apr 26 19:07:58 so i think the interrupt status bits are fine Apr 26 19:22:02 well talking to the switch on spi looks incredibly simple... Apr 26 19:22:42 <[florian]> it is supposed to be quite simple Apr 26 19:23:51 8 byte command, 8 byte address, then 8, 16, 32 byte read or write depending on command and address Apr 26 19:36:37 according to this forum i just read, bcm5325 spi pins are 5,6,7,8 Apr 26 19:55:14 ok i detect a tiny change in the voltage on what is supposed to be the MOSI pin when i start a spi transfer Apr 26 19:55:29 master out slave in? Apr 26 19:55:39 so that would make sense Apr 26 19:56:32 the slave select line is always high though Apr 26 19:59:04 or maybe it just goes low to short a time to detect Apr 26 19:59:21 <[florian]> it should be low the complete transfer time Apr 26 20:01:06 <[florian]> well assuming this is the default polarity Apr 26 20:02:30 active low is most common apparently Apr 26 20:02:48 but the transfer time is not going to be long, my multimeter probably isn't fast enough to register it Apr 26 20:14:12 nvidia driver crashed :( Apr 26 20:32:11 tripolar * r21177 /packages/net/irssi/Makefile: update irssi to 0.8.15 Apr 26 20:44:28 ok proof those 0xff come from the wire: pulling the MISO line to ground i get all 0x00 in the rx buff Apr 26 20:45:19 <[florian]> sounds correct Apr 26 20:48:29 <[florian]> you might want to check for a longer transfer and see if the chip select line is driven correctly Apr 26 20:49:14 i'm testing with a small speaker on the line Apr 26 20:49:29 i hear squeaking no matter which chip is set in the ccommand Apr 26 20:49:40 but oddly i hear the same thing on the clock line Apr 26 20:49:53 i think the speaker is probably throwing it off though Apr 26 20:49:58 hey guys, somebody has heard from Kaloz lately? I've sent him a board so maybe he could have helped me to port openwrt to it, but it's been a while Apr 26 20:50:11 <[florian]> he has been off fora while now Apr 26 20:50:22 maybe if somebody else is also interested I could ship a board to him Apr 26 20:51:02 alesan: which cpu? Apr 26 20:51:08 arm Apr 26 20:51:24 alesan: what exactly? Apr 26 20:51:38 ARM926EJ Apr 26 20:51:45 that is the core Apr 26 20:53:02 rtz2, interested :) ? Apr 26 20:53:32 alesan: well, what exactly is it? Apr 26 20:53:43 alesan: there are a number of arm targets already in openwrt Apr 26 20:54:13 rtz2, it's our own chip Apr 26 20:54:30 it has been designed in-house Apr 26 20:54:53 it has VGA output, sound, USB 2.0, H.264BP decoder etc Apr 26 20:55:01 alesan: this means I will get access to datasheets? Apr 26 20:55:18 datasheets :) Apr 26 20:55:27 we are a small team, we do not have datasheets :) Apr 26 20:55:45 <[florian]> alesan: nice Apr 26 20:55:53 but we have drivers Apr 26 20:56:01 this would be a really nice change :) Apr 26 20:56:10 <[florian]> alesan: you have done the SoC design by yourself? Apr 26 20:56:28 [florian], not MYself but with a team of course Apr 26 20:56:32 alesan: well, but I get somebody I can ask questions Apr 26 20:56:50 of course! Apr 26 20:56:51 <[florian]> alesan: sure, that's huge work, all the IPs were designed by you? Apr 26 20:57:05 [florian], only some. Not the core of course :) Apr 26 20:57:15 not the H264 decoder Apr 26 20:57:28 but the framebuffer, scaler, audio output etc Apr 26 20:57:33 <[florian]> alesan: I hope it is not some powervr stuff :) Apr 26 20:57:43 powervr...? Apr 26 20:58:03 alesan: do you have a booting kernel? Apr 26 20:58:18 <[florian]> from imagination, the same chip in iphone, and some adroid stuff Apr 26 20:58:29 n900 too Apr 26 20:58:33 <[florian]> alesan: indeed Apr 26 20:58:39 <[florian]> ali1234: indeed ;) Apr 26 20:58:46 and also poulsbo/gma500 Apr 26 20:58:52 rtz2, of course Apr 26 20:58:53 and none of them has proper drivers :( Apr 26 20:59:02 rtz2, we are running a Qt embedded application on it Apr 26 20:59:07 <[florian]> ali1234: yep, that's why I ask because that would be a pity Apr 26 20:59:15 that interfaces with regfular VGA monitor and uses USB mouse keyboard etc Apr 26 20:59:40 oh we also have android running on it even if it's kind of experimental Apr 26 20:59:47 seems like you would get more utility out of porting meego to it Apr 26 20:59:58 what is meego Apr 26 21:00:03 well, when they actually produce something Apr 26 21:00:06 meego.org Apr 26 21:00:12 <[florian]> it is the merging of moblin and maemo Apr 26 21:00:24 it's nokia and intel's linux distro for STBs, phones, in-car etc Apr 26 21:00:25 well Apr 26 21:00:30 I like Openwrt Apr 26 21:00:54 <[florian]> alesan: this does not prevent you from pushin your stuff mainline, and let people choose their prefer distro Apr 26 21:01:04 alesan: I admit my arm exprience is pretty limited, but I would be interested Apr 26 21:01:05 yes, that is a good point Apr 26 21:01:17 [florian], of course, if only the bosses would understand Apr 26 21:01:36 <[florian]> alesan: ah well, that can come later Apr 26 21:01:47 hopefully Apr 26 21:02:16 rtz2, [florian], can I send you a board each to give me a hand to create the port? Apr 26 21:02:58 <[florian]> alesan: better send it to rtz2, I have too many boards to deal with :~ Apr 26 21:02:59 alesan: sure Apr 26 21:04:06 oi guys Apr 26 21:04:19 <[florian]> hello Weedy Apr 26 21:04:21 are there and real viable dsl platforms Apr 26 21:04:56 <[florian]> Weedy: infineon stuff are doing good now Apr 26 21:04:57 alesan: is your graphics chipset able to do exotic custom modelines ie extreme overscan PAL? Apr 26 21:05:20 [florian]: are there any end user products? Apr 26 21:05:51 <[florian]> Weedy: yes, quite some, though the german devs will give you more infos about this Apr 26 21:06:10 ali1234, well, it's pretty customizable, but I am not sure until it is tested... what would you like to do? The aim is a VGA interface, not a PAL one... Apr 26 21:07:21 PAL is quite similar to VGA, just with a much lower clock Apr 26 21:08:03 but for my purpose i need more overscan than you can typically get from eg a nvidia card Apr 26 21:08:54 i've written a teletext encoder, it can send old style teletext pages in the vertical refresh period Apr 26 21:09:11 any links on hand or who should I poke Apr 26 21:09:20 <[florian]> Weedy: ask blogic Apr 26 21:09:32 i should probably just get a FPGA board or something Apr 26 21:09:55 crap Apr 26 21:10:03 @seen blogic Apr 26 21:10:12 ... oh right, my bot is not here Apr 26 21:10:24 man i get used to having her around :/ Apr 26 21:10:58 my aim is to have a mythtv box that also generates teletext pages, since they stopped broadcasting it here, but a lot of people prefer it to the digital text Apr 26 21:34:03 well that's interesting, looks like i crashed the switch by spamming it with spi :) Apr 26 21:58:09 OK i have successful comms with the switch :) Apr 26 23:07:46 nbd * r21178 /trunk/package/mac80211/patches/ (3 files): mac80211: add ap isolate support Apr 26 23:08:04 nbd * r21179 /trunk/package/hostapd/ (3 files in 2 dirs): hostapd: add ap isolate support for mac80211 **** ENDING LOGGING AT Tue Apr 27 02:59:57 2010