**** BEGIN LOGGING AT Wed Apr 07 02:59:57 2010
Apr 07 03:38:20 <philipp64> cshore: still around?
Apr 07 03:39:52 <philipp64> anyone around who understands the modules.mk files?
Apr 07 05:46:49 <builder> build #37 of rdc is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/rdc/builds/37
Apr 07 07:45:57 <CIA-39> markus * r20737 /trunk/package/broadcom-diag/src/diag.c:
Apr 07 07:45:57 <CIA-39> added WRT54G3GV2-VF detection to broadcom-diag
Apr 07 07:45:57 <CIA-39> + diag now recognizes the router
Apr 07 07:45:57 <CIA-39> + basic LEDs work
Apr 07 07:45:57 <CIA-39> - 3G LED for blink does not work as for the old version
Apr 07 07:45:58 <CIA-39> so I removed it. Maybe some GPIO probing might help.
Apr 07 08:32:54 <Lalloso> cshore: are you here?
Apr 07 09:03:15 <Acinonyx> gmorning
Apr 07 10:29:48 <stintel> I don't want to be rude or something, but imvho the period between rc3 and final was way too short. I haven't even gotten to testing rc3 yet
Apr 07 10:33:04 <stintel> don't get me wrong, I seriously appreciate all the hard work, but I fear this might hurt openwrt in general
Apr 07 10:34:53 <Kaloz> the lack of releases hurt it more ;)
Apr 07 10:36:22 <abyrne> there's already a 10.03.1 milestone, no date set yet though
Apr 07 10:42:13 <KanjiMonster> stintel: also, to be nitpicking, there shouldn't be any difference between the last rc and the final release ;)
Apr 07 10:46:22 <lalloso> cshore are you here?
Apr 07 10:48:54 <stintel> Kaloz: I understand
Apr 07 10:51:25 <stintel> I'll put final on some of my devices soon, but first must sue my previous employer :/
Apr 07 12:11:25 <lalloso> cshore ^_^
Apr 07 12:22:28 <KanjiMonster> any recommendations for jtag (ejtag) adapters (preferably not in the bdi 3000 price class ;)?
Apr 07 12:25:51 <maligor> maybe the ft2232 based stuff?
Apr 07 12:26:02 <abyrne> KanjiMonster: have you broken something? :P
Apr 07 12:26:03 <maligor> albeit I've never used them with ejtag (mips) stuff
Apr 07 12:26:31 <KanjiMonster> abyrne: no, but I plan to ;)
Apr 07 12:26:54 <KanjiMonster> also the rs pro has an ejtag port, and it would a waste to not use it ;)
Apr 07 12:26:58 <KanjiMonster> be
Apr 07 12:27:21 <abyrne> KanjiMonster: if it's your rspro and you're experimenting with yours in order to make mine better, go for it!
Apr 07 12:27:30 <KanjiMonster> (also, the redboot on the rs pro could need some additional features)
Apr 07 12:27:42 <KanjiMonster> and has some annoying bugs
Apr 07 12:28:13 <blogic> KanjiMonster: bdi3000 is worth every cent :)
Apr 07 12:28:17 * blogic loves his bdi3000
Apr 07 12:28:20 <maligor> you can get ft2232's around 50eur
Apr 07 12:28:39 <blogic> maligor: yes and grow grey hair waiting on it when you wanna debug :)
Apr 07 12:28:42 <KanjiMonster> blogic: but currently being a student without a job makes the bdi3000 a bit unaffordable ;)
Apr 07 12:28:50 <blogic> the ftdi solution + openocd works well, but is slow as hell
Apr 07 12:28:52 <maligor> blogic, well, it's worked fine for me
Apr 07 12:29:32 <abyrne> blogic: ah you're here, I want to chat to you about uci_firewall.sh
Apr 07 12:29:55 <maligor> KanjiMonster, yeah... poking around bootloaders is fun ;P
Apr 07 12:30:16 <maligor> especially if the original bootloader is rubbish
Apr 07 12:30:25 <blogic> abyrne: sure
Apr 07 12:30:26 <KanjiMonster> maligor: I also already found the sources for a ar71xx redboot, therefor it should be a bit easier
Apr 07 12:30:28 <blogic> th eipv6 thing
Apr 07 12:30:42 <maligor> like *cough* dns-323 *cough*
Apr 07 12:31:31 <maligor> never got any testers for my bootloader configuration for it
Apr 07 12:31:45 <maligor> probably because most people don't have a jtag to test it out
Apr 07 12:42:00 <KanjiMonster> can I use any "arm-jtag" adapter for ejtag (as long as it has oss drivers)?
Apr 07 12:44:13 <maligor> which one?
Apr 07 12:44:24 <maligor> you'll probably have to make your own cables
Apr 07 12:46:53 <maligor> well, more to the point, it's not a probably :P
Apr 07 12:47:39 <maligor> KanjiMonster, well... you can also build one yourself
Apr 07 12:48:21 <KanjiMonster> I have no experience in soldering
Apr 07 12:48:32 <maligor> cheapest usb ones are FT2232, and any parallel port will be a unbuffered or buffered wiggler
Apr 07 12:49:18 <maligor> well, some adapters include flying lead cables which you can use, but you can also make those yourself
Apr 07 12:49:57 <maligor> those cables won't fit into boards with 2mm headers tho
Apr 07 12:50:18 <KanjiMonster> the wigglers require a parallel port, which I don't have
Apr 07 12:51:19 <maligor> you also don't really need soldering skills to make adapter cables :P
Apr 07 12:51:49 <KanjiMonster> yeah, but to build my own jtag adapter ;)
Apr 07 12:52:32 <maligor> and you should check that the cable works with openocd and urjtag
Apr 07 12:52:59 <maligor> or atleast people seem to prefer that on mips
Apr 07 12:53:07 <maligor> never used it myself
Apr 07 12:53:44 <KanjiMonster> yeah, being compatible to openocd/urjtag is definitely a requirement for me
Apr 07 13:12:02 <mrtimlong>  hiya - how would i find out which device the ifxmips target was tested on?
Apr 07 13:13:21 <blogic> mrtimlong: by asking me
Apr 07 13:13:24 <blogic> :)
Apr 07 13:13:31 <blogic> you have annex a or b ?
Apr 07 13:18:47 <mrtimlong> blogic: :) I don't have either - but I'm looking for some an ADSL device with WiFi that will run openwrt and was trying to figure out if an ifxmips target would be the ONE
Apr 07 13:19:13 <blogic> yes
Apr 07 13:19:15 <blogic> you have annex a or b ?
Apr 07 13:19:17 <blogic> :)
Apr 07 13:19:26 <blogic> depending on this you need to get a different unit
Apr 07 13:19:35 <blogic> let me rephrase
Apr 07 13:19:41 <blogic> do you have POTS or ISDN `
Apr 07 13:19:42 <blogic> ?
Apr 07 13:20:30 <mrtimlong> oh right = POTS = A
Apr 07 13:21:33 <blogic> ok
Apr 07 13:21:49 <blogic> a zyxel multimode 2602 should do if you getr a annex-a version of it
Apr 07 13:22:02 <blogic> a zyxel multimodem 2602 should do if you getr a annex-a version of it
Apr 07 13:22:15 <blogic> but i have not added support yet
Apr 07 13:22:31 <blogic> it is all still experimental
Apr 07 13:24:32 <mrtimlong> would be happy to test it - contribute towards it if I can manage to get a hold of one
Apr 07 13:24:51 <blogic> ok
Apr 07 13:24:58 <blogic> basically, the boards are all the same
Apr 07 13:25:10 <blogic> its  matter of making a bootloader for that ram chip
Apr 07 13:25:15 <blogic> but that is rather simple
Apr 07 13:25:29 <blogic> once the board boots dsl and voip will aswell
Apr 07 13:25:52 <mrtimlong> i am in South Africa and it can be quite tricky to get a hold routers... but zyxel might be possible
Apr 07 13:26:21 <blogic> ok
Apr 07 13:26:33 <blogic> otherwise Thompson make routers with that chipset
Apr 07 13:26:41 <blogic> i think thompson is sold in SA ?
Apr 07 13:27:56 <mrtimlong> can have a look
Apr 07 13:38:08 <mrtimlong> still hunting for thomson routers (like the speedtouch?) but have found zyxel P-660HW Series - any idea about this one?
Apr 07 13:45:07 <lalloso> cshore are you availablenow? :D
Apr 07 13:47:54 <KanjiMonster> blogic: would an 2232h based jtag adapter ease the slowness a bit? I see some pcb layouts with it
Apr 07 13:51:04 <ali1234> isn't that basically just a usb to parallel port converter chip?
Apr 07 14:01:53 <blogic> 2232 is just a dual 232
Apr 07 14:03:55 <KanjiMonster> I mean the highspeed version of it http://www.ftdichip.com/Products/FT2232H.htm
Apr 07 14:05:32 <blogic> ha ok
Apr 07 14:05:37 <blogic> probably yes
Apr 07 14:10:13 <blogic> KanjiMonster: if you want a "working solution"  ... http://www.amontec.com/jtagkey.shtml
Apr 07 14:11:12 <KanjiMonster> blogic: but that one uses the "slower" full speed version, not the high speed
Apr 07 14:13:57 <KanjiMonster> ah, the jtagkey2 does have it, and is even cheaper
Apr 07 14:32:57 <cshore> ping Lalloso
Apr 07 14:33:46 <lalloso> pong cshore
Apr 07 14:34:01 <lalloso> have you read the emails from my friend emanuel?
Apr 07 14:34:08 <lalloso> may i query you a little bit?
Apr 07 14:36:19 <ali1234> is there any documentation available for the 63xx?
Apr 07 14:36:30 <ali1234> from broadcom i mean
Apr 07 14:36:44 <blogic> lol
Apr 07 14:36:46 <blogic> no
Apr 07 14:37:02 <ali1234> oh well
Apr 07 14:39:51 <ali1234> think i found what i need anyway
Apr 07 14:40:23 <ali1234> linux doesn't set the "ENET_CTL_EPHYSEL" bit if you set external phy in the board def
Apr 07 14:40:53 <[florian]> ali1234: yes, that's likely
Apr 07 14:41:05 <[florian]> ali1234: if you have any patches for this, please send them ;)
Apr 07 14:41:08 <ali1234> hi [florian], i got CFE working :)
Apr 07 14:41:14 <ali1234> trying to fix linux now
Apr 07 14:41:18 <[florian]> ali1234: great!
Apr 07 14:41:34 <[florian]> ali1234: right now ethernet does not work on bcm6338, last I checked, I was not sure if it was a DMA or switch issue
Apr 07 14:41:49 <[florian]> ali1234: I think it's a switch issue, since the DMA engine kicks off the TXing of packets
Apr 07 14:41:49 <ali1234> as i had theorized, my board does need "external phy" and "internal phy", "external switch" do not work
Apr 07 14:42:11 <ali1234> hmm ethernet does not work at all?
Apr 07 14:42:22 <ali1234> well maybe there is more problems then :/
Apr 07 14:42:22 <[florian]> ali1234: nothing goes out of the switch
Apr 07 14:42:37 <[florian]> ali1234: that's what needs to be debugged
Apr 07 14:42:38 <ali1234> well that could be the same problem
Apr 07 14:42:47 <ali1234> the 6338 only has 8 gpio right?
Apr 07 14:42:51 <[florian]> ali1234: either the bootloader does set a bad switch configuration with no default vlan
Apr 07 14:42:54 <[florian]> ali1234: yes, 8 only
Apr 07 14:43:34 <ali1234> well here, 0-5 are connected to LEDs, 6 is connected to the switch reset "pull high to enable switch) and the 7th makes the board reset if i do anything with it
Apr 07 14:44:03 <[florian]> ali1234: ok, then you might want to play with the switch reset and see what happens
Apr 07 14:44:12 <[florian]> ali1234: how is your switch control port connected?
Apr 07 14:44:17 <[florian]> ali1234: using pseudo-PHY ?
Apr 07 14:44:19 <ali1234> it isn't
Apr 07 14:44:49 <ali1234> as far as i can tell the bcm cannot control the switch in any way
Apr 07 14:44:51 <[florian]> you have no MDIO/MDC lines, but you can certainly still control vlans and such using SPI or pseudo PHY address
Apr 07 14:45:42 <ali1234> it seems to operate like a 1 port router connected to an external switch - ie it has no knwoledge of being connected to a switch and thinks it has only 1 port with external PHY
Apr 07 14:46:18 <[florian]> ali1234: ok, then the bootloader must put all ports in the same vlan and forward this back and forth the cpu port
Apr 07 14:46:33 <ali1234> the bootloader only sees 1 port
Apr 07 14:46:37 <[florian]> ali1234: or I hope, the default switch configuration does that
Apr 07 14:46:56 <ali1234> yes presumably by default the switch just acts like a hub
Apr 07 14:47:04 <[florian]> like a switch ;)
Apr 07 14:47:12 <ali1234> like a unmanaged switch, yes
Apr 07 14:47:28 <ali1234> anyway i could be completely wrong about this
Apr 07 14:47:37 <[florian]> maybe not, 6338 are cheap devies
Apr 07 14:47:39 <ali1234> but that's the settings i patched into cfe to make it work
Apr 07 14:47:43 <[florian]> s/devies/devices/
Apr 07 14:47:56 <[florian]> can you try the same trick for Linux?
Apr 07 14:48:06 <ali1234> that's why i am trying with the board settings
Apr 07 14:48:16 <[florian]> board settings are not probably enough there
Apr 07 14:48:20 <ali1234> the format is not quite the same. i tried to get it as near as possible
Apr 07 14:48:36 <ali1234> hmm 1 sec let me pastebin what i have in each
Apr 07 14:48:46 <ali1234> have you seen the 63xx boardparms.c/.h?
Apr 07 14:48:47 <[florian]> sure
Apr 07 14:48:53 <ali1234> the one from some gpl release
Apr 07 14:49:13 <[florian]> yes I have seen that
Apr 07 14:49:24 <ali1234> i used that as reference for patching CFE, seems that the structs are not quite the same in mine, but they are very similar
Apr 07 14:49:51 <ali1234> http://pastebin.com/BX8ez9LV is what i put into my cfe
Apr 07 14:51:14 <ali1234> http://pastebin.com/wkreQVS4 is what i put into my board def
Apr 07 14:51:40 <ali1234> notably, "has_phy" but "use_internal_phy=0"
Apr 07 14:51:58 <ali1234> but it seems that the driver does not understand this case and does not set the enet control regs properly
Apr 07 14:52:15 <[florian]> lines 4 to 6 are not required, by default the structure members are 0
Apr 07 14:52:29 <[florian]> ali1234: yes, the driver does not know about external phys
Apr 07 14:52:33 <ali1234> i make that assertion based on dumping the registers at 0xfffe2800 using JTAG while CFE or kernel is running
Apr 07 14:53:03 <[florian]> I was planning on adding support for external phys anyway
Apr 07 14:54:16 <ali1234> register dumps: http://pastebin.com/GwMjyJCm
Apr 07 14:55:20 <[florian]> you are close to getting it working under linux ;)
Apr 07 14:55:29 <ali1234> hope so :)
Apr 07 14:55:34 <ali1234> also my PCI does not work
Apr 07 14:55:42 <ali1234> lspci just returns nothing
Apr 07 14:55:55 <[florian]> because we do not register the PCI controller on bcm6338
Apr 07 14:56:00 <[florian]> I actually thought there was no PCI at all
Apr 07 14:56:05 <ali1234> maybe there isn't?
Apr 07 14:56:10 <[florian]> I think there is not
Apr 07 14:56:17 <ali1234> but how is my bcm4318 wireless connected if not PCI?
Apr 07 14:56:21 <[florian]> ah :)
Apr 07 14:56:32 <[florian]> bcm4318 is pci-ionly
Apr 07 14:56:37 <[florian]> so yes, there is PCI available
Apr 07 14:56:56 <[florian]> then you would need to have set HAS_PCI in arch/mips/bcm63xx/Kconfig
Apr 07 14:57:00 <[florian]> and has_pci in your board definition
Apr 07 14:57:04 <ali1234> i put "has_pci" in the board but seems it was not enough
Apr 07 14:57:55 <[florian]> ali1234: make sure that the pci registration code does not (or does) check on 6338
Apr 07 14:58:07 <ali1234> select HW_HAS_PCI is already in the Kconfig
Apr 07 14:58:42 <[florian]> bcm63xx_pci_init checks for 6348 and 6358
Apr 07 14:58:50 <[florian]> in arch/mips/pci/pci-bcm63xx.c
Apr 07 14:58:55 <[florian]> so you will need to add 6338 here as well
Apr 07 14:59:14 <[florian]> and make sure you also provide it with the MPI register base address
Apr 07 14:59:30 <ali1234> i've seen that a lot, kept wondering what it was
Apr 07 14:59:34 <cshore> ping {Nico}
Apr 07 14:59:41 <ali1234> its the first reg that CFE writes to, before it even uncompresses
Apr 07 15:00:35 <ali1234> ah good old CPU_IS_XXX() checks
Apr 07 15:03:55 <[florian]> maybe you would like to check that ethernet works before doing this ;)
Apr 07 15:04:28 <ali1234> not sure how to fix ethernet :)
Apr 07 15:04:42 <ali1234> i'd be happy if lspci at elast sees wireless
Apr 07 15:05:03 <ali1234> although b43/4318 has no AP mode support yet
Apr 07 15:05:43 <[florian]> it has
Apr 07 15:06:01 <[florian]> it's not as perfectly working as the binary broadcom driver, but it works well
Apr 07 15:06:07 <ali1234> it has? b43 webpage says it is too buggy
Apr 07 15:06:40 <[florian]> it actually works very well here
Apr 07 15:07:12 <ali1234> under "not working" : "AP mode using 4318 because of packet loss in high transmission rates. Hard to debug & fix. "
Apr 07 15:07:31 <ali1234> well, if it works, all the better
Apr 07 15:13:55 <[florian]> ali1234: so, to start with ethernet, I would make it accept external phy and make it set the correct bits if so
Apr 07 15:14:29 <ali1234> i'm compiling a list of all regs that are different and what they mean
Apr 07 15:15:00 <[florian]> ali1234: you can counter-check with the linux ethernet driver sources
Apr 07 15:15:23 <ali1234> i'm getting register meaning from bcm63xx_regs.h
Apr 07 15:15:29 <[florian]> yes
Apr 07 15:28:40 <ali1234> hmm i could do with setting up external git
Apr 07 15:29:11 <[florian]> why do you want to do that?
Apr 07 15:29:26 <ali1234> because git is extremely helpful
Apr 07 15:29:30 <OutBackDingo> xMff: which iptables module is MASQUERADE in ??
Apr 07 15:41:34 <ali1234> if i'm reading this right then the enet interrupt reg shows pending interrupts from MIB in my CFE dump, and from MII and FLOWC in kernel dump
Apr 07 15:43:14 <ali1234> also CFE sees a lot of data in the MIB register but in kernel it is all blank
Apr 07 16:02:53 <ali1234> [florian]: got a panic with pci because 6338 does not have pcmcia http://pastebin.com/9QYLeH25
Apr 07 16:03:21 <ali1234> don't know if i should surround that bit with a cpu check, move it inside the following #ifdef, or something else
Apr 07 16:03:40 <ali1234> manuconfig happily lets you select bcm63xx pcmcia support, maybe that should be changed too?
Apr 07 16:04:22 <[florian]> ali1234: you do not have cardbus
Apr 07 16:04:36 <ali1234> yeah i know
Apr 07 16:04:49 <[florian]> ali1234: it is not that simple to mask cardbus options
Apr 07 16:05:05 <[florian]> ali1234: because we can run the same kernel on 6338, 6348, 6358 ...
Apr 07 16:05:18 <ali1234> hmm good point
Apr 07 16:05:46 <ali1234> thing is that bcm_pcmcia_readl(PCMCIA_C1_REG) causes unaligned access error because the pcmcia addr is "0xdeadbeef"
Apr 07 16:06:07 <ali1234> or maybe it is the write that crashes, not that it matters
Apr 07 16:06:27 <ali1234> so should i just surround it with a CPu check?
Apr 07 16:06:28 <[florian]> ali1234: just maake sure that you do not have has_pccard set
Apr 07 16:06:32 <[florian]> ali1234: yes
Apr 07 16:06:38 <ali1234> has_pccard is unset
Apr 07 16:21:42 <[florian]> ali1234: is it better now?
Apr 07 16:21:49 <ali1234> still compiling
Apr 07 16:22:25 <ali1234> for some reason it takes 30 minutes when i type "make" in the build system after modifying only one file in the kernel
Apr 07 16:23:28 <cshore> hi....I've got a package that has an included version of sqlite, but it's getting conflicts because it somehow triggers the build of the OpenWRT version, even though the package doesn't have sqlite in it's Makefile at all (i.e. it's not a DEPENDS, anywhere).  Any clues?  Can libtool cause the build of an OpenWRT version of a library or something?
Apr 07 16:24:07 <cshore> I need the included one because the it is modified from the standard version
Apr 07 16:25:06 <ali1234> 01:1e.0 CardBus bridge: Broadcom Corporation Device 6338 :) :) :)
Apr 07 16:25:34 <ali1234> but i don't see anything attached to it...
Apr 07 16:25:57 <cshore> Also, no sqlite packages are selected when I look at menuconfig
Apr 07 16:26:00 <[florian]> ali1234: are you sure you did commented the right portion of the code?
Apr 07 16:26:08 <ali1234> commented?
Apr 07 16:26:09 <cshore> so it's not a dependency
Apr 07 16:26:13 <[florian]> ali1234: ermm, add the 6338 check
Apr 07 16:26:29 <ali1234> hmm i put it around the cardbus stuff
Apr 07 16:27:22 <ali1234> pci 0000:00:00.0: unknown header type 5e, ignoring device
Apr 07 16:27:27 <ali1234> i see a lot of that stuff
Apr 07 16:28:45 <[florian]> can you show me the complete log?
Apr 07 16:29:04 <[florian]> ali1234: you might want to check against a broadcom consumer release for any specific PCI configuration
Apr 07 16:29:21 <[florian]> ali1234: also, what does your original firmware bootlog shows about pci?
Apr 07 16:29:36 <ali1234> original firmware doesn't say much about anything
Apr 07 16:29:53 <ali1234> log: http://pastebin.com/pc6vm4p4
Apr 07 16:30:40 <[florian]> no idea where that comes from
Apr 07 16:30:46 <[florian]> however, it seems like one pci device is enabled
Apr 07 16:30:53 <[florian]> is b43 recognized?
Apr 07 16:31:22 <ali1234> i don't think so
Apr 07 16:31:43 <[florian]> what about /proc/bus/pci/devices?
Apr 07 16:32:15 <ali1234> 01f0	14e46338	fffe0200 (followed by some zeros)
Apr 07 16:32:51 <[florian]> ok, it's the broadcom vendor ID and 0x6338
Apr 07 16:33:04 <[florian]> that's not ok
Apr 07 16:33:43 <[florian]> ali1234: make sure that BCM6338 does not enable the cardbus idsel
Apr 07 16:34:09 <[florian]> ali1234: the rest should be fine
Apr 07 16:35:08 <[florian]> ali1234: also, you might want to check that bcm63xx_fixup does nothing bad
Apr 07 16:37:35 <thepeople> stintel: we are working to a better release process moving forward
Apr 07 17:53:53 <ali1234> hmm i'm getting somewhere. ethernet is now receiving but not transmitting :)
Apr 07 17:54:53 <ali1234> but one thing i don't understand. looking at the source, the EPHY bit should be turned on by bcm_enet_hw_preinit
Apr 07 17:55:00 <ali1234> something must be later turning it off again
Apr 07 17:57:13 <ali1234> or maybe enet_writel(priv, val, ENET_CTL_REG) does not do what i think it does
Apr 07 18:42:39 <ali1234> is there some buildsystem target to just rebuilt vmlinux.elf?
Apr 07 18:44:52 <ali1234> i'm looking through the ethernet code, it does write 0x8 into the control reg, but that's all
Apr 07 18:45:02 <ali1234> at some point it has to write 0x01 to enable the thing
Apr 07 18:45:32 <ali1234> looks like instead of writing oldvalue|0x1 it just writes 0x1, which clears the EPHY bit
Apr 07 18:45:56 <xMff> the closest target is make target/linux/{clean,compile}
Apr 07 18:46:10 <ali1234> ah thanks, i knew clean but not compile
Apr 07 18:50:53 <CIA-39> jow * r20738 /packages/net/cups-bjnp/ (. Makefile): [packages] add cups-bjnp, a CUPS backend for proprietary Canon printer protocol
Apr 07 19:01:28 <ali1234> found it, i was right :)
Apr 07 19:05:02 <ali1234> unfortunately "make target/linux/compile" does not rebuild vmlinux.elf
Apr 07 19:05:12 <ali1234> although it did rebuild something
Apr 07 19:10:15 <xMff> you sure?
Apr 07 19:10:21 <xMff> did you cleaned it before?
Apr 07 19:10:33 <ali1234> no
Apr 07 19:10:44 <ali1234> if i clean it i'll lose all my changes :)
Apr 07 19:12:18 <xMff> did you rm'd vmlinux.elf at least?
Apr 07 19:12:45 <ali1234> let me try that...
Apr 07 19:35:36 <ali1234> ok tried it, it doesn't rebuild
Apr 07 19:36:02 <xMff> maybe you need to remove the .compiled stampfile
Apr 07 19:37:04 <ali1234> where is that? actually find didn't find it...
Apr 07 20:33:56 <ali1234> [florian]: i have enet rx working, but tx does not work. also some irq weirdness. messing about with the irq_mask reg i managed to get "irq 16: nobody cared" error. ifconfig says eth0 uses irq 16... any ideas?
Apr 07 20:39:05 <lfcorreia> hi all
Apr 07 20:39:17 <lfcorreia> a question if I may
Apr 07 20:40:09 <lfcorreia> building from SVN, it is still called Kamikaze in the busybox banner :)
Apr 07 20:40:49 <ali1234> hmm it's true...
Apr 07 20:43:43 <ali1234> do you have the latest SVN? i suspect that the banner might have been changed when backfire final was released, which was today
Apr 07 20:46:31 <KanjiMonster> lfcorreia: are you building trunk or the backfire branch?
Apr 07 20:46:32 <thepeople> trunk = kamikaze, 10.03 = backfire
Apr 07 20:46:57 <thepeople> trunk will get its own code name sometime in the near future
Apr 07 20:47:17 <ali1234> heh, that's not confusing at all :)
Apr 07 20:47:54 <thepeople> well we are going to a more "standard" way of code naming things
Apr 07 20:48:10 <KanjiMonster> btw, is it intentional that all codenames are vodka based cocktails? ;)
Apr 07 20:48:20 <thepeople> maybe ;-)
Apr 07 20:48:48 <thepeople> (it is)
Apr 07 20:50:23 <KanjiMonster> the codenames would make a good basis for openwrt release parties - why are there none? ;)
Apr 07 20:51:17 <thepeople> KanjiMonster: maybe the users should throw the devs a release party :-)
Apr 07 20:53:29 <stintel> hehe yeah I felt like having a backfire too ;)
Apr 07 20:53:42 <stintel> my rspro doesn't seem to like it though
Apr 07 20:54:01 <stintel> and I dont drink alcohol for now so it'll have to wait
Apr 07 20:54:04 <xMff> it will adept
Apr 07 20:54:04 <acoul1> why not cross compile everywhere:  https://dev.openwrt.org/changeset/11542/trunk/package/grub ?
Apr 07 20:54:42 <acoul1> r11542 breaks soekris support on x86-32bit archs
Apr 07 20:54:46 <thepeople> acoul1: no idea
Apr 07 20:55:21 <acoul1> cross compiling grub fixes this issue
Apr 07 20:55:40 <thepeople> acoul1: if it breaks things I would say revert it and fix the real issue on OS X
Apr 07 20:56:19 <thepeople> becuase if you don't cross compile it it will match the host which could be i686 when it is being installed on a i486 device
Apr 07 20:57:24 <acoul1> yes correct
Apr 07 20:57:44 <acoul1> so cross compile always then
Apr 07 20:58:15 <thepeople> I think so
Apr 07 21:23:11 <CIA-39> acoul * r20739 /trunk/package/grub/Makefile: package/grub: play it safe, cross compile everywhere
Apr 07 21:33:06 <CIA-39> jow * r20740 /trunk/package/broadcom-wl/ (files/lib/wifi/broadcom.sh src/wlc/wlc.c): [brcm-2.4] broadcom-wl: implement "hwmode" uci option, supports 11b (B only), 11g (G only), 11gst (G performance) and 11bg (default)
Apr 07 21:35:52 <CIA-39> jow * r20741 /branches/backfire/package/broadcom-wl/ (files/lib/wifi/broadcom.sh src/wlc/wlc.c): [backfire] merge r20740
Apr 07 22:40:30 <lfcorreia> KanjiMonster, sorry, got AFK
Apr 07 22:40:44 <lfcorreia> i'm building on trunk, hence, Kamikaze :P
Apr 07 22:40:54 <lfcorreia> thanks to all for the explanation
Apr 07 22:49:10 <philipp64> any hardware folks around?  got a couple of questions as I try to add a new platform type.
Apr 07 22:50:22 <philipp64> here goes: (1) some h/w drivers will burp an error message if they fail to detect the appropriate hardware, but not all will. from what I can tell, certain drivers will load up and stay resident even if they fail to locate corresponding hardware.  is this correct?
Apr 07 22:51:04 <rtz2> philipp64: by driver, you mean the module or the struct device_driver?
Apr 07 22:51:19 <philipp64> (2) I'm building a subtarget of x86, and as it comes up it tells me it has a bunch of CPU support.  how do I disable the unneeded CPU support?
Apr 07 22:51:27 <philipp64> rtz2: the module.
Apr 07 22:52:09 <rtz2> philipp64: modules are only unloaded explicitly with rmmod
Apr 07 22:52:23 <rtz2> philipp64: no matter what hardware you have
Apr 07 22:52:52 <rtz2> philipp64: as for the cpus, there are config symbols for them
Apr 07 22:53:46 <rtz2> and the loading of a module will always succeed (if it isn't buggy and all needed symbols are there), regardless of the actual hardware
Apr 07 22:54:34 <philipp64> and (3) on astlinux, ehci_hcd comes up because it requests (and gets) interrupt 7.  on openwrt it fails because mfgpt has already gotten that irq. (on astlinux, mfgpt uses IRQ 6)
Apr 07 22:55:48 <philipp64> rtz2: ok, so is there an easy way to tell if the h/w you think is present really, really is?  the manual for the net5501 is non-existent.
Apr 07 22:56:00 <rtz2> philipp64: /sys
Apr 07 22:56:23 <rtz2> philipp64: as for (3), I don't know how the irq request and routing system on x86 works, sorry
Apr 07 22:56:31 <philipp64> rtz2: I'm an old IOS hacker... so you'll need to give me an occasional hint... :-)
Apr 07 22:56:41 <rtz2> no problem
Apr 07 22:56:58 <philipp64>  /sys what?
Apr 07 22:58:09 <rtz2> philipp64: it gives you lot's of informations about the devices known to the kernel
Apr 07 22:58:27 <rtz2> philipp64: in /sys/bus you have a list of busses like pci and usb
Apr 07 22:58:48 <rtz2> philipp64: they have a devices subdirectory
Apr 07 22:59:07 <rtz2> (and drivers where you can find the drivers loaded for devices on the bus)
Apr 07 22:59:29 <rtz2> there is also the platform bus, where everything ends up, that doesn't fit anywhere
Apr 07 23:00:09 <rtz2> but be aware, that not all buses can be probed
Apr 07 23:00:12 <philipp64> rtz2: so stuff that lspci wouldn't show ends up there?
Apr 07 23:00:27 <rtz2> lspci only shows stuff on the pci bus
Apr 07 23:00:33 <rtz2> and not for example the usb bus
Apr 07 23:00:58 <rtz2> pci and usb for example can be probed, the kernel can discovere all devices connected to it
Apr 07 23:01:11 <philipp64> right... not that I built lspci... forgot to turn it on.  :-(
Apr 07 23:02:07 <rtz2> philipp64: but there are usually a bunch of devices, that are simply acces by writing to the right registers
Apr 07 23:02:47 <rtz2> you can't autodected those devices, you simply have to know, which registers to probe and if the device is present
Apr 07 23:03:23 <rtz2> that's usually the case for stuff like gpios and leds and sometimes also network or usb devices
Apr 07 23:03:46 <rtz2> you have to add stuff like that manually to the platform bus
Apr 07 23:04:37 <philipp64> rtz2: ok, so if I loaded the nsc_gpio or hwmon-pc87360 drivers and they failed to find corresponding hardware, what would be the smoking gun?
Apr 07 23:06:35 <rtz2> philipp64: most likely, you have to add those devices manually
Apr 07 23:07:12 <rtz2> philipp64: it's not really complicated, it boils down to telling the kernel, that a device name "nsc_gpio" (or whatever the driver expects) is there
Apr 07 23:07:22 <philipp64> rtz2: ok, I'm unclear.
Apr 07 23:07:49 <philipp64> say I've manually done a insmod of nsc_gpio and it fails to find the register-signature that says that chipset is present.
Apr 07 23:08:06 <philipp64> what happens next?  would it fail to populate /sys/bus/platform/devices?
Apr 07 23:10:22 <rtz2> philipp64: devices and drivers are basically independent of each other
Apr 07 23:10:45 <rtz2> philipp64: you can have a device without a driver and a driver without a device
Apr 07 23:11:07 <rtz2> philipp64: the driver core makes sure, to them together
Apr 07 23:11:33 <rtz2> the driver doesn't create the device, that happens somewhere else
Apr 07 23:11:47 <rtz2> philipp64: do you have the source for the nsc_gpio driver somewhere?
Apr 07 23:11:56 <philipp64> yes.
Apr 07 23:12:07 <rtz2> http://lxr.linux.no/#linux+v2.6.31/drivers/char/nsc_gpio.c ?
Apr 07 23:15:42 <rtz2> ok, I checked the nsc_gpio driver and the module init code does create it's own platform device
Apr 07 23:15:44 <philipp64> yup.
Apr 07 23:15:50 <rtz2> it shouldn't actually do this, but ok
Apr 07 23:16:28 <rtz2> you have the scx200 or pc8736x?
Apr 07 23:17:14 <rtz2> philipp64: the nsc_gpio module is no acutal driver, only a bunch of functions
Apr 07 23:17:34 <rtz2> you need one of those two to use the device
Apr 07 23:17:37 <philipp64> again, that's what I'm trying to determine.
Apr 07 23:17:47 <rtz2> try both
Apr 07 23:18:22 <philipp64> I've loaded the pc8736x_gpio... how do I know if it found h/w?
Apr 07 23:19:21 <xMff> ls -lR /sys/class/gpiodev/gpio/  maybe?
Apr 07 23:24:14 <rtz2> shouldn't it be /sys/class/gpio/?
Apr 07 23:26:14 <xMff> not sure
Apr 07 23:26:32 <philipp64> there's a /sys/class/cs5535_gpio but no other gpio's.
Apr 07 23:27:12 <rtz2> philipp64: well, then the driver didn't get loaded
Apr 07 23:27:50 <rtz2> philipp64: you can also check dmesg, those drivers seemed to print an error, if they don't found their device
Apr 07 23:28:18 <philipp64> platform pc8736x_gpio.0: NatSemi pc8736x GPIO Driver Initializing
Apr 07 23:28:19 <philipp64> platform pc8736x_gpio.0: GPIO ioport 6600 reserved
Apr 07 23:28:48 <rtz2> philipp64: check /sys/bus/platform/devices
Apr 07 23:29:05 <ali1234> thing about GPIO is its one of those devices you can't probe
Apr 07 23:29:20 <ali1234> so the driver itself probably won't know if the hardware is really there
Apr 07 23:29:48 <rtz2> ali1234: the module init code does some pokeing and creates the platform dev
Apr 07 23:29:59 <philipp64> geodewdt        pc8736x_gpio.0  serial8250
Apr 07 23:30:01 <philipp64> i8042           rtc_cmos
Apr 07 23:30:17 <philipp64> but that's weird, because I'm pretty sure there is no i8042 device.
Apr 07 23:31:15 <rtz2> check, if there is a driver dir in pc8736x_gpio.0
Apr 07 23:31:47 <philipp64> no: modalias, power, subsystem, uevent ... no driver
Apr 07 23:33:27 <rtz2> philipp64: ok
Apr 07 23:33:55 <rtz2> philipp64: the pc8736x_gpio seems to do some pretty nonstandard things
Apr 07 23:34:15 <rtz2> it doesn't register a normal gpio driver, only some kind of char device
Apr 07 23:34:50 <rtz2> philipp64: but basically, it should be there
Apr 07 23:34:57 <rtz2> philipp64: check /dev/
Apr 07 23:35:29 <philipp64> only /dev/cs5535_gpio*
Apr 07 23:35:58 <philipp64> also noticed that the kmod-hwmon-pc87360 didn't get built. sigh.
Apr 07 23:36:56 <philipp64> ok, let's start with something simple... how to reassign the IRQ's so that the USB and MFGPT stuff doesn'
Apr 07 23:36:59 <philipp64> doesn't clash?
Apr 07 23:37:33 <rtz2> this is actually rather hard
Apr 07 23:37:43 <rtz2> philipp64: check /sys/dev/char/
Apr 07 23:37:55 <rtz2> philipp64: one of them has to be your gpio device
Apr 07 23:38:20 <rtz2> philipp64: as for the irq problem, you have to check the drivers
Apr 07 23:38:28 <rtz2> and find out, where they get the irq from
Apr 07 23:39:10 <philipp64> nope... they are all cs5535_gpio devices.
Apr 07 23:39:39 <rtz2> philipp64: load the module with a major= argument
Apr 07 23:39:45 <rtz2> minor number should be 0
Apr 07 23:45:16 <philipp64> which one?
Apr 07 23:46:54 <rtz2>  pc8736x_gpio
Apr 07 23:48:03 <philipp64> and what value as the major number?
Apr 08 00:00:30 <rtz2> no idea, pick one
Apr 08 00:21:44 <CIA-39> nico * r20742 /tags/backfire_10.03/: tag 10.03
Apr 08 00:26:37 <CIA-39> mirko * r20743 /packages/Xorg/lib/qt4/Makefile:
Apr 08 00:26:37 <CIA-39> enable linux framebuffer support for Qt
Apr 08 00:26:37 <CIA-39> (besides support for DirectFB)
Apr 08 00:27:52 <CIA-39> mirko * r20744 /packages/libs/libsdl/Makefile:
Apr 08 00:27:52 <CIA-39> enable linux framebuffer support for SDL
Apr 08 00:27:52 <CIA-39> (besides support for DirectFB)
**** ENDING LOGGING AT Thu Apr 08 02:59:56 2010