**** BEGIN LOGGING AT Thu Apr 08 02:59:56 2010
Apr 08 07:09:46 <[florian]> ali1234: ping?
Apr 08 07:53:17 <CIA-39> florian * r20745 /trunk/target/linux/generic-2.6/ (6 files in 6 dirs): [kernel] fix kexec for mips, patch from Adrian Byszuk (#7115)
Apr 08 08:39:28 <Acinonyx> gmorning
Apr 08 10:15:58 <Lalloso> cshore your latest package work
Apr 08 10:39:57 <ali1234> [florian]: hi
Apr 08 10:45:39 <ali1234> [florian]: i've already seen that mips kexec patch, didn't make any noticable difference for me
Apr 08 11:41:12 <Kimvais> anyone run remote kgdb on ppc40x on backfire branch successfully?
Apr 08 11:42:06 <Kimvais> I get busyloop in init process, kernel boots fine, until run_init_process is called, but then nothing happens (or in the best case bust_spinlocks() is called and I get a panic for killing init)
Apr 08 11:45:15 <Kimvais> oh, actually, I get the same without kgdb
Apr 08 11:45:51 <Kimvais> same being "Kernel panic - not syncing: Attempted to kill init!"
Apr 08 11:53:35 <[florian]> ali1234: hi
Apr 08 11:53:45 <[florian]> ali1234: I wanted to talk about enet on bcm63xx
Apr 08 11:53:51 <ali1234> good :)
Apr 08 11:53:57 <ali1234> cos i am out of ideas
Apr 08 11:54:00 <[florian]> ali1234: so you got tx working, at some point
Apr 08 11:54:09 <[florian]> ali1234: that's also what I was seeing on my 6338 device
Apr 08 11:54:14 <ali1234> hmm no, just rx
Apr 08 11:54:34 <ali1234> i can ping from another machine and RX packet count increases
Apr 08 11:54:43 <[florian]> ah, that's good
Apr 08 11:54:45 <ali1234> but when i send packets, TX count does not increase
Apr 08 11:54:56 <[florian]> what does /proc/interrupts says?
Apr 08 11:55:01 <[florian]> does the number of tx interrupts increase?
Apr 08 11:55:32 <ali1234> dunno... which is TX?
Apr 08 11:55:54 <ali1234> http://pastebin.com/xUUv55AC
Apr 08 11:56:10 <ali1234> oh 389 is how many packets i received
Apr 08 11:56:21 <ali1234> so i guess 23&24 = RX&TX
Apr 08 11:56:47 <ali1234> thing is, CFE operates with interrupts completely disabled
Apr 08 11:57:05 <ali1234> i tried with and without interrupts in the board file but i get the same result
Apr 08 11:57:39 <[florian]> I do not think you will get something working without interrupts in the linux ethernet driver
Apr 08 11:58:29 <[florian]> let me think about where the problem comes from
Apr 08 11:58:54 <ali1234> in that case it is probably just because i did not set the right interrupt
Apr 08 11:59:22 <ali1234> external phy needs external interrupt right?
Apr 08 11:59:23 <[florian]> not necessarily it can be the DMA engine which does not kick txing
Apr 08 11:59:33 <ali1234> hmm ok
Apr 08 11:59:36 <[florian]> external phy do not need interrupt
Apr 08 11:59:42 <[florian]> and the phy interrupt is just there in case the link changes
Apr 08 11:59:58 <[florian]> the actuall tx/rx paths are from the ethernet MAC
Apr 08 12:00:10 <[florian]> so you would have two interrupts lines for this
Apr 08 12:00:16 <ali1234> ok
Apr 08 12:01:58 <[florian]> last I checked, I do not think there was a mistake in the interrupt lines for tx
Apr 08 12:02:06 <[florian]> so I guess this is DMA which does not kick
Apr 08 12:02:12 <[florian]> and this is a bit harder to debug
Apr 08 12:02:43 <[florian]> do you think you can try dumping the skb that the hardware is supposed to send?
Apr 08 12:02:58 <[florian]> and check that the descriptors point to the appropriate location
Apr 08 12:03:31 <ali1234> what's an skb?
Apr 08 12:03:45 <[florian]> a skb is the structure which is used by linux to describe packets
Apr 08 12:03:55 <[florian]> ethernet frames, IP packets ...
Apr 08 12:04:05 <ali1234> struct sk_buff... ok i'll have a god
Apr 08 12:04:07 <ali1234> *go
Apr 08 12:04:59 <[florian]> you will most likely need to add printk in the bcm_enet_start_xmit function
Apr 08 12:07:08 <ali1234> what am i looking for inside it? dev/rx_dev?
Apr 08 12:09:27 <[florian]> ali1234: you can check for instance that the dma descriptor (desc) is valid
Apr 08 12:09:49 <[florian]> ali1234: and print the skb->data field after desc->address was set
Apr 08 12:10:03 <[florian]> ali1234: make sure that this one is a valid ethernet/IP packet
Apr 08 12:12:31 <ali1234> right, building
Apr 08 12:12:47 <ali1234> i also hit a dead end with PCI. the MPI registers just are not there
Apr 08 12:14:12 <ali1234> looking at the board it doesn't look like there are enough datalines to the wireless for it to be PCI
Apr 08 12:14:15 <blogic> ps
Apr 08 12:19:42 <[florian]> ali1234: it might be sdio then
Apr 08 12:19:51 <[florian]> ali1234: but I did not know that bcm4318 could be sdio connected
Apr 08 12:21:23 <ali1234> it looks like it has about 6 or 7 data lines
Apr 08 12:22:01 <[florian]> might very well be sdio then
Apr 08 12:23:46 <[florian]> there seems to have been versions of bcm4318 with sdio, I did not know that
Apr 08 12:33:12 <ali1234> [florian]: seems like it never gets as far as calling bcm_enet_start_xmit
Apr 08 12:33:53 <[florian]> ali1234: humm, sure of that?
Apr 08 12:34:32 <ali1234> well the printk does not fire
Apr 08 12:34:46 <[florian]> did you put it right at the beginning of the function?
Apr 08 12:34:51 <ali1234> yes
Apr 08 12:34:59 <[florian]> ok, then yes, it's not going to work :)
Apr 08 12:53:36 <Kimvais> a newbie question; can I modify the source code in build_dir/, run make and have that source code in bin/ or does it get overwritten by stuff downloaded and patched?
Apr 08 12:53:50 <ali1234> you can do that
Apr 08 12:54:00 <ali1234> as long as you dont touch anything in packages/
Apr 08 12:54:05 <Kimvais> hmm, wonder why the busybox does not print me any init debugs then
Apr 08 12:55:52 <Kimvais> does anyone have the current svn backfire branch running on a kilauea board?
Apr 08 12:56:43 <Kimvais> or other ppc40x platform, or any powerpc arch
Apr 08 12:57:20 <Kimvais> because I'm starting to think that the problems with init / busybox I am having are not particular to my setup
Apr 08 13:07:14 <KanjiMonster> a quick boot of 2.6.32.11 on ar71xx didn't show any problems, looks like it might be safe to update to it
Apr 08 13:15:40 <Lalloso> cshore: ?
Apr 08 13:58:32 <ali1234> [florian]: when i try to ping something it always goes on to lo instead of eth0. routing table looks ok...
Apr 08 14:00:12 <[florian]> ali1234: that's really strange
Apr 08 14:00:26 <[florian]> ali1234: does eth0 have any IP address :p ?
Apr 08 14:00:32 <ali1234> yes
Apr 08 14:00:51 <cshore> pong Lalloso
Apr 08 14:01:09 <ali1234> i traced through net/core/dev.c and it calls the ndo_start_xmit but not the one of the bcm_enet
Apr 08 14:01:19 <ali1234> i even tried with ping -I eth0
Apr 08 14:01:25 <[florian]> and nothing more?
Apr 08 14:01:44 <ali1234> it appears to successfully send the packet out of lo but it gets no response
Apr 08 14:02:00 <[florian]> it should not send it using lo, but eth0
Apr 08 14:02:05 <ali1234> since i didn't put any tracing into the lo driver i dunno what happens next
Apr 08 14:02:26 <ali1234> i'm putting in some more tracing to check the dev in dev.c
Apr 08 14:02:29 <[florian]> it should not use the loopback, there is a problem with the routing table
Apr 08 14:02:45 <ali1234> 192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
Apr 08 14:02:49 <ali1234> that's all i have
Apr 08 14:03:04 <ali1234> local ip is 192.168.0.77 remote is 192.168.0.1
Apr 08 14:03:23 <[florian]> this should be fine
Apr 08 14:03:27 <[florian]> can you force a default route ?
Apr 08 14:03:48 <[florian]> also, it might be worth playing with arp to see if you can send arp sollicitations and receive them
Apr 08 14:03:51 <ali1234> 0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 eth0
Apr 08 14:04:04 <ali1234> same result
Apr 08 14:05:16 <ali1234> arp says: 192.168.0.1      0x1         0x0         00:00:00:00:00:00     *        eth0
Apr 08 14:05:22 <ali1234> but only after i pinged that ip
Apr 08 14:05:38 <[florian]> so rx does not work either I'd say
Apr 08 14:05:43 <[florian]> otherwise the mac address would be correct
Apr 08 14:05:47 <ali1234> no, it really does :)
Apr 08 14:06:02 <[florian]> does tcpdump also agrees ;) ?
Apr 08 14:06:12 <ali1234> need to install it...
Apr 08 14:06:34 <[florian]> I would like to make sure the packets are not stripped or badly received
Apr 08 14:11:48 <ali1234> 00:02:20.221963 ARP, Request who-has 192.168.0.77 tell 192.168.0.5, length 46
Apr 08 14:11:52 <ali1234> i get a lot of that on tcpdump
Apr 08 14:12:08 <ali1234> no actual pings, because it does not succesfully send a arp response
Apr 08 14:12:17 <[florian]> correct
Apr 08 14:12:41 <[florian]> can you force the ethernet address associated with 192.168.0.1
Apr 08 14:12:59 <ali1234> you mean .77?
Apr 08 14:13:00 <[florian]> to see if that helps making packets go out using the right interface ;) ?
Apr 08 14:13:12 <[florian]> the destination IP address you want to ping
Apr 08 14:13:24 <ali1234> i never managed to make that work, how exactly do i do it?
Apr 08 14:14:01 <ali1234> btw i am using 00:11:22:33:44:55 as mac
Apr 08 14:14:20 <[florian]> arp -s address hw_addr
Apr 08 14:14:38 <[florian]> this is fine as a mac adddress
Apr 08 14:16:32 <ali1234> i added the mac to the arp table on ym workstation, got this: 00:06:58.403088 IP 192.168.0.5 > 192.168.0.77: ICMP echo request, id 59976, seq 16, length 64
Apr 08 14:16:47 <[florian]> that's a good start :)
Apr 08 14:17:02 <ali1234> and i see the dev.c tracing trying to reply
Apr 08 14:17:08 <ali1234> but not the tracing from bcm_enet
Apr 08 14:17:16 <[florian]> you should add your workstation mac address on the bcm6338 arp table as well
Apr 08 14:17:52 <ali1234> identical result
Apr 08 14:18:17 <[florian]> now try to ping from the bcm6338 to the workstation and see if it uses the right interface
Apr 08 14:18:55 <ali1234> nope, it is still incrementing the counters on lo
Apr 08 14:19:17 <[florian]> crap, what's happening
Apr 08 14:19:28 <ali1234> dunno, but recompile with more tracing finished, let me try that
Apr 08 14:20:52 <ali1234> "Sending a packet on lo"
Apr 08 14:20:56 <ali1234> there is the smoking gun
Apr 08 14:21:08 <ali1234> dev->name = "lo"
Apr 08 14:21:37 <[florian]> ok, so either busybox's ping is too stupid to correctly the output interface
Apr 08 14:21:44 <[florian]> or the networking stack does weird things
Apr 08 14:27:31 <ali1234> hum... dev is inside the skb
Apr 08 14:27:37 <ali1234> struct net_device *dev = skb->dev;
Apr 08 14:30:13 <ali1234> dev = dev_get_by_index(sock_net(sk), ifindex);
Apr 08 14:33:11 <[florian]> ali1234: seems like busybox ping is doing bad things
Apr 08 14:33:31 <ali1234> i never had a problem with it before...
Apr 08 14:33:45 <[florian]> neither had I, but here, I do not see why the wrong device is used
Apr 08 15:02:15 <ali1234> get_dev_by_index is returning eth0
Apr 08 15:02:46 <ali1234> but then somewhere between that and sending the packet it reverts back to lo, without another call to get_dev_by_index
Apr 08 15:10:58 <[florian]> weird
Apr 08 15:11:29 <ali1234> i wish the kernel would compile faster, half an hour is too long :(
Apr 08 15:11:42 <[florian]> make target/linux/install rebuilds only the kernel
Apr 08 15:12:08 <ali1234> ah, thanks, i'll try that
Apr 08 15:16:21 <ali1234> hmm it looks like it is trying to send the packet out of eth0 and failing for some reason, then it tries lo
Apr 08 15:21:51 <[florian]> ah, that would explain why it tries the loopback
Apr 08 15:22:31 <ali1234> hmm think i have a theory
Apr 08 15:22:37 <ali1234> something to do with checksumming
Apr 08 15:24:14 <[florian]> ali1234: right
Apr 08 15:25:18 <ali1234> nope, it gets through that func ok
Apr 08 15:33:38 <ali1234> hmm... seems related to QDISC
Apr 08 15:39:16 <ali1234> ah here we go: ndo_select_queue
Apr 08 15:39:28 <ali1234> i think it is returning a bad queue, the packet gets queued, and never goes anywhere
Apr 08 15:40:04 <ali1234> but bcm_enet_ops does not define it
Apr 08 15:43:36 <[florian]> bcm63xx_enet does not support multiqueue
Apr 08 15:43:43 <[florian]> so it should not define this callback
Apr 08 16:00:12 <ali1234> right, it doesn't define it. i've traced as far as qdisc_enqueue_root and it looks like everything is fine until there
Apr 08 16:00:27 <ali1234> but it seems like it never makes it out the other side of the queue
Apr 08 16:38:52 <ali1234> [florian]: so here it is: http://pastebin.com/wKFvCHJL
Apr 08 16:39:00 <ali1234> the Qdisc just eats the packets :/
Apr 08 16:39:30 <[florian]> ali1234: that's really really weird
Apr 08 16:39:40 <[florian]> ali1234: I am wondering if the dma engine is not corrupting the skb
Apr 08 16:40:29 <ali1234> the dma engine is not going anywhere near it
Apr 08 16:40:35 <ali1234> it doesn't get as far as that
Apr 08 16:40:52 <ali1234> well, unless the dma is wildly thrashing through memory for some reason
Apr 08 16:41:02 <ali1234> ha!
Apr 08 16:41:26 <ali1234> maybe that's why i sometimes get a 32 bytes of zeros when i flash a trx with mtd
Apr 08 16:41:37 <[florian]> can be
Apr 08 16:42:01 <ali1234> i did download the trx to /tmp and it nearly filled memory
Apr 08 16:42:34 <ali1234> maybe it is just corrupting the same small piece of ram over and over
Apr 08 16:42:39 <ali1234> well, i can test that with devmem...
Apr 08 16:43:24 <[florian]> ah maybe we have different dma channels
Apr 08 16:43:40 <[florian]> can you try changing priv->rx_chan and priv->tx_chan ?
Apr 08 16:43:49 <ali1234> where?
Apr 08 16:43:59 <[florian]> in bcm63xx_enet.c, probe function
Apr 08 16:44:26 <ali1234> /* get rx & tx dma channel id for this mac */
Apr 08 16:44:33 <ali1234> just below that?
Apr 08 16:44:36 <[florian]> yes
Apr 08 16:44:48 <ali1234> 2 & 3 maybe?
Apr 08 16:44:59 <ali1234> thing is, rx works...
Apr 08 16:45:27 <[florian]> just change the tx channel then
Apr 08 16:47:50 <ali1234> changed both, now rx does not work
Apr 08 16:48:03 <ali1234> and tx is still the same
Apr 08 16:51:18 <[florian]> ali1234: ok
Apr 08 16:51:23 <[florian]> ali1234: so there must be something else
Apr 08 16:51:29 <ali1234> shouldn't the dma... be enabled?
Apr 08 16:51:54 <[florian]> it is enabled
Apr 08 16:52:06 <ali1234> ENETDMA_CFG_EN_MASK = 0
Apr 08 16:53:27 <ali1234> oh nvm, reading the dump wrong
Apr 08 16:53:35 <ali1234> anyway, dinner time, bbiab
Apr 08 17:42:35 <ali1234> q->ops->id = noop
Apr 08 17:43:39 <ali1234> noop_dequeue just returns NULL
Apr 08 17:44:14 <ali1234> "NOOP" scheduler: the best scheduler, recommended for all interfaces under all circumstances. It is difficult to invent anything faster or cheaper.
Apr 08 17:44:24 <ali1234> (because it just drops all packets)
Apr 08 17:45:52 <ali1234> so i look in kernel config... net_sched is enabled but no schedulers are selected...
Apr 08 18:15:53 <stintel> hmmm, backfire image for rspro contains switch config but the switch isn't supported ?
Apr 08 18:20:12 <thepeople> stintel: I thought that the support landed before -final
Apr 08 18:21:08 <stintel> thepeople: heh, it was you who told me it wouldnt "{
Apr 08 18:21:13 <stintel> :p&
Apr 08 18:21:15 <stintel> ]argfh
Apr 08 18:21:22 <stintel> typo mania
Apr 08 18:22:48 <thepeople> I know, that is becuase it didn't look like it would
Apr 08 18:26:19 <KanjiMonster> hmm
Apr 08 18:29:45 <KanjiMonster> stintel: I tftpbooted the backfire kernel and it didn't detect the switch, but I wonder why
Apr 08 18:32:08 <thepeople> KanjiMonster: -final?
Apr 08 18:32:35 <KanjiMonster> http://downloads.openwrt.org/backfire/10.03/ar71xx/openwrt-ar71xx-vmlinux.elf <- that one
Apr 08 18:34:39 <KanjiMonster> looks like the kernel wasn't rebuild
Apr 08 18:35:42 <KanjiMonster> "strings openwrt-ar71xx-vmlinux.elf | grep ar8216" yields only "<3>ar8216: timeout waiting for operation to complete", but should also have "<3>ar8216: Unknown Atheros device [ver=%d, rev=%d, phy_id=%04x%04x]"
Apr 08 18:38:10 <KanjiMonster> which looks for me like the backfire release was built from a dirty buildroot
Apr 08 18:39:46 <KanjiMonster> thepeople: who is responsible for the builds?
Apr 08 18:42:47 <acoul1> ping florian
Apr 08 19:03:39 <thepeople> KanjiMonster: {Nico} build 10.03
Apr 08 19:04:19 <KanjiMonster> thepeople: thanks
Apr 08 19:04:27 <KanjiMonster> {Nico}: ping
Apr 08 19:09:51 <{Nico}> KanjiMonster: pong
Apr 08 19:10:52 <KanjiMonster> {Nico}: the backfire kernel for ar71xx is missing the [ar8216] changes from r20723
Apr 08 19:12:01 <KanjiMonster> wait
Apr 08 19:12:04 <KanjiMonster> now I see it
Apr 08 19:12:18 <KanjiMonster> r20723 missed the ar8216 changes from r20722
Apr 08 19:13:23 <KanjiMonster> I'll open a ticket - 'thought it was a build problem
Apr 08 19:27:32 <xMff> KanjiMonster: I looked three times at the merge commit but cannot spot what's missing... do you have an incremental patch?
Apr 08 19:28:18 <KanjiMonster> xMff: the whole first patch is missing (all changes to target/linux/generic-2.6 )
Apr 08 19:28:24 <KanjiMonster> I'll look if I still have it
Apr 08 19:28:49 <xMff> generic-2.6/files/drivers/net/phy/ar8216.[ch] ?
Apr 08 19:29:20 <KanjiMonster> yes
Apr 08 19:29:26 <xMff> but it is there
Apr 08 19:29:33 <xMff> https://dev.openwrt.org/changeset/20722
Apr 08 19:29:37 <xMff> https://dev.openwrt.org/changeset/20723
Apr 08 19:30:11 <KanjiMonster> you are righy
Apr 08 19:30:14 <KanjiMonster> *right
Apr 08 19:30:23 <KanjiMonster> I was browsing in the wrong path
Apr 08 19:30:29 <xMff> I see
Apr 08 19:30:46 <{Nico}> so definitely a build issue ?
Apr 08 19:31:04 <KanjiMonster> yes, must be
Apr 08 19:31:44 <{Nico}> i didn't force a kernel rebuild
Apr 08 19:32:08 <KanjiMonster> this might have been the problem
Apr 08 19:32:16 <{Nico}> probably
Apr 08 19:32:42 <KanjiMonster> while developing I often stumbled over the rebuild not picking up changes in target/*/files/*
Apr 08 19:33:26 <{Nico}> i think we're relying on the kernel build system to rebuild stuff touched
Apr 08 19:35:18 <KanjiMonster> stuff changed in build_dir/linux-*/linux-*/ gets rebuild
Apr 08 19:36:11 <{Nico}> humm, strange
Apr 08 19:36:12 <{Nico}> [openwrt@wrt1 ar71xx]$ grep CONFIG_AR8216_PHY build_dir/linux-ar71xx/linux-2.6.32.10/.config
Apr 08 19:36:15 <{Nico}> CONFIG_AR8216_PHY=y
Apr 08 19:36:45 <{Nico}> [openwrt@wrt1 ar71xx]$ ls -l build_dir/linux-ar71xx/linux-2.6.32.10/drivers/net/phy/ar8216.o
Apr 08 19:36:48 <{Nico}> -rw-rw-r-- 1 openwrt openwrt 10956 Apr  6 04:03 build_dir/linux-ar71xx/linux-2.6.32.10/drivers/net/phy/ar8216.o
Apr 08 19:37:21 <KanjiMonster> does a 'strings ar8216.o | grep ar8316' yield anything?
Apr 08 19:38:37 <KanjiMonster> my guess is: build_dir/linux-.. already existed, and only the timestamp in target/linux/generic-2.6/files/.../phy was newer, but generic-2.6/ wasn't, so it didn't trigger a clean rebuild
Apr 08 19:38:53 <KanjiMonster> *generic-2.6/files
Apr 08 19:39:01 <{Nico}> yeah, files where not overwritten :/
Apr 08 19:39:01 <KanjiMonster> if it uses the timestamps
Apr 08 19:40:40 <{Nico}> [openwrt@wrt1 ar71xx]$ ls -l build_dir/linux-ar71xx/linux-2.6.32.10/drivers/net/phy/ar8216.c target/linux/generic-2.6/files/drivers/net/phy/ar8216.c
Apr 08 19:40:44 <{Nico}> -rw-rw-r-- 1 openwrt openwrt 14746 Mar 19 21:08 build_dir/linux-ar71xx/linux-2.6.32.10/drivers/net/phy/ar8216.c
Apr 08 19:40:47 <{Nico}> -rw-rw-r-- 1 openwrt openwrt 18823 Apr  6 03:07 target/linux/generic-2.6/files/drivers/net/phy/ar8216.c
Apr 08 19:41:28 <thepeople> KanjiMonster: it might be useful if you jot this down in ticket as well (buildsystem rebuild fubar)
Apr 08 19:41:41 <KanjiMonster> okay
Apr 08 19:41:55 <thepeople> so we can track/fix it
Apr 08 19:41:56 <{Nico}> KanjiMonster: you can event quote me :)
Apr 08 19:42:05 <{Nico}> sorry guys, i have to go
Apr 08 19:42:09 <thepeople> bye {Nico}
Apr 08 19:48:33 <CIA-39> zandbelt * r20746 /packages/net/asterisk-1.4.x/Makefile: add required libpopt dependency for asterisk14-mini; fixes #7112
Apr 08 20:08:12 <ali1234> [florian]: i got enet working!
Apr 08 20:10:06 <ali1234> it was simple: the packets were discarded because it thought there was no cable connected to the external phy
Apr 08 20:10:29 <ali1234> so it looks like i need the force options. but those are ignored if .has_phy is set
Apr 08 20:12:05 <ali1234> maybe it is as simple as not setting .has_phy
Apr 08 20:12:28 <ali1234> that means my board config for enet0 would be identical to the existing ones :)
Apr 08 20:15:46 <ali1234> argh it worked :/
Apr 08 20:15:55 <ali1234> my board just picked up an ip from dhcp
Apr 08 20:16:14 <ali1234> so it was just a matter of using the right board config all along - and fixing one minor bug that i found yesterday
Apr 08 20:20:10 <ali1234> in that case, fixing the bug might "break" all the other boards
Apr 08 20:20:16 <ali1234> since they will try to use external phy now
Apr 08 20:20:31 <ali1234> you might need to add in a .use_internal_phy = 1 to them all
Apr 08 20:20:55 <ali1234> of course, if they currently don't work... it might just fix them :)
Apr 08 20:22:47 <acoul1> nice  ali1234 !!
Apr 08 20:23:01 <ali1234> where should i send patches btw?
Apr 08 20:23:13 <ali1234> is there a git tree for brcm63xx i can work against?
Apr 08 20:23:27 <acoul1> you can use trac --> create a ticket and attach patches
Apr 08 20:25:06 <acoul1> and you can probably use this git repo: http://nbd.name/gitweb.cgi?p=openwrt.git;a=summary
Apr 08 20:25:35 <ali1234> hmm that's all of openwrt... there isn't a git just for kernel stuff?
Apr 08 20:25:47 <acoul1> http://nbd.name/gitweb.cgi?p=openwrt.git;a=tree;f=target/linux/brcm63xx;h=ec2127b515b2b958740b8d131a18395b9f9942a9;hb=HEAD
Apr 08 20:25:53 <ali1234> or does nobody else use 63xx...
Apr 08 20:26:52 <acoul1> nighty nighty
Apr 08 20:36:23 <[florian]> ali1234: oh you are right!
Apr 08 20:36:47 <ali1234> i am? about which thing?
Apr 08 20:37:17 <[florian]> ali1234: about the fact that it was expecting a link
Apr 08 20:37:48 <ali1234> what about internal/external?
Apr 08 20:38:06 <ali1234> the only bug is that the current code, when it enables the enet, nukes the internal/external bit
Apr 08 20:38:08 <[florian]> ali1234: I do not understand how you got them working, by setting external or internal phy?
Apr 08 20:38:21 <danitool> [florian]: i was probing to change phy on eth1 of livebox, but with no success
Apr 08 20:39:07 <[florian]> danitool: ok, then I will have a look at it
Apr 08 20:39:15 <ali1234> [florian]: i just fixed that bug, now it works :)
Apr 08 20:39:21 <danitool> i have modified dev-enet.c, line 152, and it changes the phy but only in eth0
Apr 08 20:39:57 <danitool> and after this none of ethernets work
Apr 08 20:39:58 <[florian]> ali1234: ok, can you generate a patch from the linux-mips.org repository? or from the openwrt sources?
Apr 08 20:40:25 <ali1234> [florian]: i already have, i'm doing a full rebuild of the kernel now to make sure it actually works... it's literally a 3 liner though
Apr 08 20:40:39 <[florian]> ali1234: excellent
Apr 08 20:40:49 <ali1234> also to clean up all the printks i added :)
Apr 08 20:41:02 <ali1234> printk spam was getting out of hand
Apr 08 20:41:04 <[florian]> ali1234: eh eh
Apr 08 20:48:30 <ali1234> yes, it works
Apr 08 20:48:44 <[florian]> ali1234: can you show me the diff?
Apr 08 20:49:10 <ali1234> http://pastebin.com/HB5pAw5i
Apr 08 20:49:41 <ali1234> it ORs the register with 1 to enable, rather than just writing a 1
Apr 08 20:50:40 <ali1234> this means that any board that had .use_internal_phy	= 0 was using internal phy anyway
Apr 08 20:50:51 <[florian]> correct
Apr 08 20:51:13 <ali1234> so any board which had that, and used to work, needs to have .use_internal_phy = 1 instead
Apr 08 20:51:51 <ali1234> not sure what it means for enet1
Apr 08 20:51:55 <[florian]> did you make any changes to board_bcm963xx.c ?
Apr 08 20:52:04 <ali1234> i added a new board config for my board
Apr 08 20:52:10 <[florian]> if I recall right, internal phy is only available to enet0
Apr 08 20:52:16 <ali1234> but it seems it wasn't necessary
Apr 08 20:52:16 <[florian]> enet1 is usually connected to a switch
Apr 08 20:52:26 <ali1234> the existing ones would have worked
Apr 08 20:52:47 <[florian]> is it different from 6338W which is already present?
Apr 08 20:52:49 <ali1234> well, except that i need to pull a gpio to enable the switch, but my patched cfe does that
Apr 08 20:53:25 <ali1234> it has one more LED than the 6338W
Apr 08 20:53:37 <ali1234> other than that it is the same afaik
Apr 08 20:53:46 <ali1234> enet0 section is identical
Apr 08 20:53:59 <ali1234> but my board is called "CANT-P" (which is a very silly name)
Apr 08 20:58:31 <[florian]> ali1234: ok
Apr 08 20:58:43 <ali1234> board file http://pastebin.com/1N20W13Y
Apr 08 20:59:44 <[florian]> ali1234: ok, I will test your bcm63xx_enet.c change and see if that works on my 6338W as well
Apr 08 21:00:43 <ali1234> if enet works in CFE and you have jtag, just look at 0xfffe282c and if it = 9, you need external phy :)
Apr 08 21:01:52 <ali1234> hmm... so ... wireless next
Apr 08 21:02:29 <[florian]> about that, first you would need a spi driver to work
Apr 08 21:02:44 <[florian]> then I think that you should be able to use the b43-sdio driver which is already merged mainline
Apr 08 21:03:02 <ali1234> ah yes, i have seen the kernel config for bcm63xx-spi but i always just get a bit banging driver
Apr 08 21:03:13 <[florian]> yes, because I removed the driver
Apr 08 21:03:18 <[florian]> it needs a bit of rework
Apr 08 21:03:39 <[florian]> first all the register specific access should be moved to the driver, while I used to put them in arch/mips/bcm63xx/cpu.c
Apr 08 21:03:50 <[florian]> that made it difficult to update from one kernel version to another
Apr 08 21:05:37 <[florian]> I will try to add back support for it this weekend
Apr 08 21:05:52 <ali1234> thanks
Apr 08 21:06:00 <ali1234> the other thing is dsl...
Apr 08 21:06:09 <ali1234> i heard that doesn't work at all
Apr 08 21:06:18 <[florian]> well yes, we have no open source driver for it
Apr 08 21:07:01 <ali1234> i see
Apr 08 21:07:12 <ali1234> there is a closed driver?
Apr 08 21:07:31 <[florian]> people who are under nda have the sources of thhe dsl driver
Apr 08 21:07:48 <[florian]> but they are not allowed to publish it, nor even a rewritten version
Apr 08 21:08:15 <ali1234> but... can i get hold of a binary version of it somewhere?
Apr 08 21:08:26 <ali1234> i'm not under any NDA :)
Apr 08 21:09:04 <[florian]> unfortunately no, because people usually do not publish binary versions for the kernel we are intrested in
Apr 08 21:09:53 <ali1234> well that's ok, i'll just use their kernel version to reverse engineer it :)
Apr 08 21:10:01 <[florian]> right now it's a dead end, but I am fairly confident someone can get something working
Apr 08 21:10:22 <[florian]> dsl is not an easy task, beware ;)
Apr 08 21:10:57 <ali1234> how does it communicate? shared memory interface with the DSP?
Apr 08 21:11:16 <[florian]> yes, that's it, a zone of the ram is used to pass messages between the CPU and the DSP
Apr 08 21:11:35 <[florian]> you basically have a SAR engine which does the segmentation and reassmebly of ATM cells
Apr 08 21:11:52 <[florian]> and the DSL engine which does the modulation on the wire
Apr 08 21:12:03 <ali1234> hmm that's done in the kernel?
Apr 08 21:12:07 <[florian]> that one is CPU intensive and thus uses a dsp
Apr 08 21:12:11 <[florian]> it depends
Apr 08 21:12:21 <[florian]> there are soft and hard implelementations
Apr 08 21:12:29 <[florian]> bcm6338 does softdsl
Apr 08 21:12:52 <ali1234> so it doesn't just emit packets of whatever type...
Apr 08 21:13:02 <ali1234> pppoe or pppoa
Apr 08 21:13:03 <[florian]> no it's much more complicated
Apr 08 21:13:25 <rtz2> ali1234: there are 2 dsl drivers in openwrt, you can take a look at them
Apr 08 21:13:40 <[florian]> yes,they provide good examples of how it works
Apr 08 21:13:54 <rtz2> ali1234: this won't be a weekend project
Apr 08 21:13:57 <[florian]> and they are pretty similar in terms of hardware architecture to broadcom
Apr 08 21:14:44 <[florian]> I am off to bed now, see you tomorrow
Apr 08 21:15:03 <ali1234> k, goodnight
Apr 08 21:22:21 <rtz2> ali1234: but having brcm63xx dsl support would be pretty nice
Apr 09 01:01:37 <CIA-39> swalker * r20747 /packages/net/tor/Makefile: [packages] tor: update to 0.2.1.25
Apr 09 01:47:11 <philipp64> where does logging go?
Apr 09 01:49:37 <philipp64> doesn't seem to be persistent.
Apr 09 01:51:43 <philipp64> anyone still here?
Apr 09 01:54:50 <CIA-39> swalker * r20748 /packages/utils/stress/Makefile: [packages] stress: update to 1.0.4, fix description display
Apr 09 02:16:28 <cshore_> philipp64: logging goes to RAM unless you configure it to go to file
Apr 09 02:16:39 <philipp64> ok, how's that?
Apr 09 02:18:10 <philipp64> I'm looking at "System Logging Utilities" in my .config
Apr 09 02:18:31 <cshore_>  look at the the UCI documentation on the wiki under /etc/config/system
Apr 09 02:19:11 <cshore_> it's runtime configuration not compile time
Apr 09 02:19:52 <philipp64> ok, will do.  one other question...  I'm adding a new target, and it has kmod-hwmon-pc87360... and my config-default contains "CONFIG_HWMON=y" but it's still not being built.  no idea why.
Apr 09 02:22:01 <cshore_> sorry, no idea
**** ENDING LOGGING AT Fri Apr 09 02:59:56 2010