**** BEGIN LOGGING AT Fri Jan 08 02:59:57 2010 Jan 08 08:51:07 do mips with floating point exist? Jan 08 08:54:04 <[florian]> yes, some cpus have a hardware floating point unit Jan 08 08:54:13 <[florian]> like the rm5200 cpus used in Cobalt Qube for instance Jan 08 08:54:18 <[florian]> but other SGI machines also have one Jan 08 08:54:33 <[florian]> none of the mips32r1/r2 which are found on embedded do have one though Jan 08 09:08:22 [florian]: 24Kf/24KEf? :P Jan 08 09:09:06 [Kaloz]: Hey has Florian bugged you about svn access for me lately? Jan 08 09:09:34 yeah Jan 08 09:10:59 I'll get it done this weekend, had and have to take care about a few other stuff first Jan 08 09:11:48 Kaloz: ok thanks Jan 08 09:12:39 I'm not sure what email I was using then (might have been brucetelecom) but my email is now cshore@csolve.net. SSH key is the same Jan 08 09:13:56 or crazycshore@gmail.com (it's my backup email) Jan 08 09:15:08 sounds like you've been insanely busy though Jan 08 09:16:30 [Florian]: for the LED on the GW devices, is there any way I can figure out what GPIO's to use without the info from Tecom...they seem to be reluctant to part with the information Jan 08 09:16:50 other than what we've already got Jan 08 09:18:28 I'm just about ready to post the updated preinit changes (about half an hour or so) Jan 08 09:18:37 to the -devel list Jan 08 09:23:01 <[florian]> cshore: you really need the led / gpio mapping from tecom, they should not reluctant to share that info Jan 08 09:23:32 <[florian]> cshore: otherwise you will have to try asserting/deasserting the 37 gpios to figure out which one controls which led Jan 08 09:24:39 cshore: which device are you working on? Jan 08 09:25:27 [florian]: which reminds me...is it normal to get an OOPS if its the wrong line? If not then the last time I tried the LEDs there was a problem with the code because I got one Jan 08 09:25:39 <[florian]> no it's not normal Jan 08 09:25:49 [danage]: BCM6348GW - Tecom GW6000 Jan 08 09:25:58 nice Jan 08 09:26:39 will you get eth on that one? Jan 08 09:26:42 [florian] would it help if I captured the serial console so you can see the OOPS Jan 08 09:26:48 <[florian]> danage: it works already Jan 08 09:26:53 nice Jan 08 09:27:01 <[florian]> mind the 48 :) Jan 08 09:27:03 <[florian]> not 45 :) Jan 08 09:27:19 yeah, was about to ask... different eth Jan 08 09:27:46 danage: has b43 wireless and vlans too...the FXS/FXO DSP should happen this year too Jan 08 09:28:00 fun Jan 08 09:28:27 sorry not vlans...wrong device...but the rest it has Jan 08 09:29:33 Florian: speaking of GW6000 vlan, is it possible for it to work via MDIO, or is it totally impossible to get vlan on that device? Jan 08 09:30:42 <[florian]> cshore: if I recall right, the broadcom reference design connects the switch over spi Jan 08 09:30:49 <[florian]> cshore: so it should be possible to get it working Jan 08 09:31:25 [florian]: which were the unconnected wires on that device (Tecom did something strange IIRC) Jan 08 09:31:46 <[florian]> cshore: the mdio/mdc lines were not corrected afair Jan 08 09:32:22 ah, ok, so it might be possible to use the SPI instead of MDIO (which works on the 6200 but can't on the 6000) Jan 08 09:32:46 <[florian]> indeed Jan 08 09:32:54 <[florian]> I still plan on getting spi in a workable state Jan 08 09:32:57 <[florian]> and merged mainline Jan 08 09:33:02 cool Jan 08 09:33:15 <[florian]> driving the switch over spi is a good way to know if it works Jan 08 09:34:31 this weekend/next week I'm working on usb root Jan 08 09:35:43 but figuring out how to deal with changing sdX devices with multiple connected USB devices is a pain Jan 08 09:36:02 <[florian]> yeah, well it's a little less painful with udev probably Jan 08 09:37:06 I'm thinking of requiring that when doing firstboot there only be the root USB...then we save the UUID of the filesystem (created during firstboot), since once the we have the UUID we can find the right device even if the device name changes Jan 08 09:37:40 udev's got that problem too....it just gives you easier access to the 'path-id' or 'uuid' Jan 08 09:38:13 <[florian]> using uuid sounds like a good plan Jan 08 09:40:24 I can use the uuid without required udev...dd and knowing the format the ext2/3/reiserfs superblock is enough (I think those are the supported Linux fses at the moment) Jan 08 09:40:35 cshore: you mean rootfs on usb? or the usb root device? Jan 08 09:40:43 rootfs on usb Jan 08 09:41:42 yeah, i think grub has started uuid for that recently too Jan 08 09:41:45 I need it, my employer needs it, and it's a frequently requested feature Jan 08 09:41:50 *using Jan 08 09:42:10 ehhh... determining the correct boot partition that is Jan 08 09:42:29 yes....it's necessary since the device names are not persistent Jan 08 09:43:28 sounds like a cool feature. where do you store the correct uuid though and how do you determine it the first time you need it? Jan 08 09:49:31 well I've been tossing around a few ideas...NVRAM or creating a single erase block scratchpad, for instance Jan 08 09:58:09 I'm planning on treating the usbroot almost like jffs ... the binary data (and /etc) partition is alway part1 and there is always a data partition part2....data is left alone on firmware flash, but the binary (root) partition is reformatted on flash...since we know what partition we're formatting we can find the uuid after doing so. The caveat is that when flashing the firmware we have to only have one USB device (and if we don't w Jan 08 09:58:29 mass storage device I mean Jan 08 09:59:21 oh wait...now I remember...the flash will be used to store the UUID Jan 08 09:59:43 it's used for that and as a fallback if the usbroot is unavailable Jan 08 10:00:57 other than part1 and 2 being required the partitioning scheme is up to the user Jan 08 10:02:36 I also plan on having a failsafe mode option that is entered via reset button while in failsafe mode, that automatically partitions sda (but requires there *only* be sda) Jan 08 10:03:11 basically it should be possible to reset the device without a serial console Jan 08 10:03:14 sounds great. i wonder how portable that would be Jan 08 10:04:26 well I think it'd work with any device that has a jffs2 mtd device and USB (on OpenWRT) Jan 08 10:04:51 but I'm not that familiar with with devices other than the brcm63xx Jan 08 10:05:53 the reset button is the biggest problem....there'd be a serial console way to do that too, but I'm not sure there a consistent interface for accessing the buttons and leds Jan 08 10:07:14 or is there something you're thinking of specifically that might be a problem (like devices that use USB as an MTD device) Jan 08 10:07:55 this is all userspace stuff that I'm doing Jan 08 10:09:42 all I do is modify preinit, mount_root, firstboot, and sysupgrade (they're all scripts) Jan 08 10:10:15 and some Makefiles and such on the build side Jan 08 10:10:56 that is modify base-files and create some packages Jan 08 10:11:27 I'm just reworking it with some changes needed to be more robust than the first version I posted Jan 08 10:42:27 thx guys for the infos about mips and fpu Jan 08 10:47:08 <{Nico}> 'lo Lalloso Jan 08 10:53:27 hello {Nico} happy new year Jan 08 10:58:14 <{Nico}> Lalloso: to you too Jan 08 10:58:43 <{Nico}> Lalloso: any news/work on FS recently? Jan 08 10:59:30 no i've back to work since yesterday Jan 08 10:59:46 problems will arise again as soon as i'll start working with it again Jan 08 10:59:56 i think we could wait for 1.0.5 in these days what do you think? Jan 08 11:00:31 I think it's the best thing to do since many patches may have been already "included in trunk" and bug fixes maybe Jan 08 11:01:09 Lalloso: about when do you think it will be out? Jan 08 11:01:44 i think in a couple of week and not more Jan 08 11:01:54 www.freeswitch.org Jan 08 11:02:10 they have finished with the prereleases i think Jan 08 11:02:15 I'm going to be working with it soon too Jan 08 11:02:22 cshore: are you also interested in freeswitch? Jan 08 11:03:33 yes...we're investigating it compared to Asterisk for telephony on an brcm63xx-based device Jan 08 11:04:23 interesting Jan 08 11:04:28 i'm also involved in such a project Jan 08 11:04:42 <{Nico}> we should test an pre-release then Jan 08 11:05:46 cshore: i'm also involved in a similar project Jan 08 11:05:59 i want to understand if a DSP is really necessary to encode some audio codec like G.729 Jan 08 11:06:18 or if is there enough power to do a few transcoding legs in software Jan 08 11:06:29 freeswitch is too good to be compared with asterisk Jan 08 11:06:34 Lalloso: cool...you can do without for initial testing but for the number of calls you need them Jan 08 11:07:03 Lalloso: depends on how much you're trying to put through the device Jan 08 11:07:34 Lalloso: what makes it so much better? Jan 08 11:08:10 lots of things Jan 08 11:08:18 the architecture is rock stable Jan 08 11:08:31 and provides a lot of performance Jan 08 11:08:47 the community is wonderful, effective and it's evolving very fast Jan 08 11:09:11 moreover i have never seen something where is so easy to create complex services Jan 08 11:09:23 it provides API in a pletory of languages Jan 08 11:11:04 it can provides webex services Jan 08 11:11:14 like cisco Jan 08 11:11:16 for free Jan 08 11:11:35 in a day you can develop a full featured services in your favourite language Jan 08 11:11:42 from perl to ruby to c to javascript Jan 08 11:11:48 cool Jan 08 11:11:52 i't just amazing Jan 08 11:12:23 i still remember the first time i telnetted into localhost port 8021 Jan 08 11:12:32 and typed event xml all Jan 08 11:13:02 that way you get everything it's happening in xml ready to be integrated in a web portal Jan 08 11:13:20 the only problem is that it seems harder than expected to port it on embedded hw Jan 08 11:13:25 right Jan 08 11:13:33 but we are facing this with the help of {Nico} :) Jan 08 11:13:41 <{Nico}> hehe Jan 08 11:13:48 <{Nico}> most of the work is done now Jan 08 11:13:53 it makes heavy use of threads i think Jan 08 11:14:00 and also it uses a library called spandsp Jan 08 11:14:02 <{Nico}> and the FS devs are supporting us :) Jan 08 11:14:05 for transcoding Jan 08 11:14:12 what about the Python dependencies? Jan 08 11:14:13 cool Jan 08 11:14:15 {Nico} are you still in contact with michael jerris? Jan 08 11:14:52 <{Nico}> humm, i failed to honor my promises to test recent trunk Jan 08 11:14:53 cshore: do you mean http://wiki.freeswitch.org/wiki/Mod_python ? Jan 08 11:14:54 Lalloso: does freeswitch support some of the voip hardware built into routers? Jan 08 11:15:10 i'm not sure about this Jan 08 11:15:13 <{Nico}> but will test rc as soon as i have some time to do so Jan 08 11:15:21 could you be more specific danage? Jan 08 11:15:27 it already works with some hardware from sangoma Jan 08 11:15:33 but as far as i know Jan 08 11:15:52 cause that would be really awesome. well a lot of routers have voip built in, at least here in germany. i.e. they have ATA or in some cases even ISDN, dsps and so forth Jan 08 11:15:56 up to now it's been mostly used in production as a replacement for high end solutions which do hundreds of calls per second Jan 08 11:16:05 most of that isn't usable under openwrt Jan 08 11:16:15 ah ok Jan 08 11:16:25 well it has this module http://wiki.freeswitch.org/wiki/OpenZAP Jan 08 11:16:40 and something here also http://www.sangoma.com/products/hardware_products/ Jan 08 11:16:48 but correct me if i'm wrong Jan 08 11:16:56 most DSP for audio as the one from audiocodes Jan 08 11:17:08 or the ones from legerity or vocallo Jan 08 11:17:15 or am i totally off-track here... wouldn't freeswitch, provided there are proper drivers, enable the use of these devices? Jan 08 11:17:16 work with proprietary APIs Jan 08 11:18:02 i'm not sure danage but i think we have to investigate further Jan 08 11:18:05 yeah the DSP in our router uses audiocodes Jan 08 11:18:20 which chip chsore? :-) Jan 08 11:18:35 there's many different ones. fpgas in some cases too Jan 08 11:18:42 danage i'm not sure about that because i think that you are asking if freeswitch could benefit of a /dev/dspsomething Jan 08 11:18:46 not sure...I'll have to ask (not my department) Jan 08 11:18:55 usually freeswich does everything in software therefore i'm not sure Jan 08 11:19:25 i know for sure that the consulting services of freeswich have already done something similar, maybe they want to keep that part for themselves in order to earn some money and eat :-) Jan 08 11:19:27 Lalloso: yes, that's probably my question, if through an interface, the onboard telephony hardware would be usable Jan 08 11:20:02 eating is good Jan 08 11:20:17 if you understand C code i can point you to a few reference file to understand how it's done Jan 08 11:20:46 all the math of the voip Jan 08 11:21:01 coding / decoding is done via this library http://www.soft-switch.org/downloads/spandsp/ Jan 08 11:21:21 which is reused by many freeswitch modules such as mod_celt Jan 08 11:21:24 mod_voipcodecs Jan 08 11:21:27 etc... Jan 08 11:21:55 the RTP is all abstracted in freeswitch because the principle is to do the least processing possible Jan 08 11:22:20 also in my view the sofia sip stack used by freeswitch is way better than chan_sip Jan 08 11:23:07 Lalloso: thanks but me personally, no coder :( Jan 08 11:23:57 no worry Jan 08 11:24:32 you could come on #freeswitch some time or ask some of the core developer if my answer was right or not Jan 08 11:28:05 there was also this module for hw boards http://fisheye.freeswitch.org/browse/FreeSWITCH/src/mod/codecs/mod_dahdi Jan 08 11:39:19 Lalloso, I might look into this once I finish usbrootfs Jan 08 11:43:30 good, let us know Jan 08 12:00:27 Kaloz, [florian] no mips on embedded device right? Jan 08 12:00:37 as far as i've understood from your brief chat Jan 08 12:00:46 sorry i mean no mips with FPU Jan 08 12:10:07 <[florian]> Lalloso: there are on mips 24kf Jan 08 12:10:15 <[florian]> f standing for floating Jan 08 13:12:58 [florian]: but are there devices which work with openwrt and have 24kf? Jan 08 13:13:25 <[florian]> Lalloso: afaik, no Jan 08 13:14:06 ah shame Jan 08 13:15:02 I guess I should abandon MIPS then if fixed point arithmetic won't suffice Jan 08 13:15:33 is there any other embedded with openwrt and FPU on architectures which are not mips? Jan 08 13:15:54 <[florian]> some powerpc platform I guess Jan 08 13:35:27 juhosg * r19075 /trunk/target/linux/ar71xx/ (files/arch/mips/ar71xx/mach-dir-825-b1.c image/Makefile): ar71xx: add missing flash partition for the DIR-825 Jan 08 14:28:22 danage: I think we should populate the redlinks in the doc: namespace with stubs to allow ppl. working on it without going through the inbox Jan 08 14:29:11 and we should probably start a FAQ Jan 08 14:29:37 i've done a minor minor edit the other day, but i have a memorandum i must submit by the end of the day that i'm still working on. i should have some time during the weekend for wiki-gardening Jan 08 14:30:15 kay. somearticles resurrected from oldwiki: still have artefacts from moinmoin in them, those should be cleaned up as well Jan 08 14:30:27 jow_laptop: faq ack, but we must take great care as to prevent redundancies imho, you think it might be fair to link to specific wiki articles as answes to faqs? Jan 08 14:30:48 yes Jan 08 14:30:57 k Jan 08 14:31:01 Bartman007: you up? Jan 08 14:31:24 i guess not Jan 08 14:31:44 jow_laptop: we should ask him to put the template he had created way back in time to new wiki, so we have something to work with Jan 08 14:32:01 isn't it already there? Jan 08 14:32:12 it is even in use as far as I remember Jan 08 14:32:12 i think i should also improve upon the router description page template, so people won't leave the false information in there when they use it Jan 08 14:32:22 i tried the other day but got linked to oldwiki Jan 08 14:32:28 I see Jan 08 14:32:32 prolly my mistake though Jan 08 16:55:17 nbd * r19076 /trunk/package/mac80211/patches/ (3 files): mac80211: various wds related fixes Jan 08 16:55:21 nbd * r19077 /trunk/package/hostapd/ (6 files in 2 dirs): hostapd: upgrade to latest version Jan 08 16:56:41 nbd * r19078 /trunk/package/mac80211/patches/ (6 files): mac80211: fix patch naming Jan 08 19:46:11 nbd: new hostapd / madwifi fail to build now Jan 08 19:46:31 ../src/drivers/driver_madwifi.c: In function 'madwifi_get_seqnum': Jan 08 19:46:31 ../src/drivers/driver_madwifi.c:518: error: 'WPA_KEY_RSC_LEN' undeclared (first use in this function) Jan 08 19:47:25 odd Jan 08 19:47:26 i'll take care of it Jan 08 20:22:57 juhosg * r19079 /trunk/target/linux/ar71xx/files/drivers/net/ag71xx/ (ag71xx.h ag71xx_debugfs.c ag71xx_main.c): ar71xx: add NAPI statistics to the ag71xx driver Jan 08 21:25:41 nbd * r19080 /trunk/package/hostapd/patches/120-compile_fix.patch: hostapd: fix compile error with madwifi enabled Jan 08 21:27:24 Hi. Could someone enlighten me why patches from target/linux/generic-2.4 are being applied during the build process when I am building a different target? Jan 08 21:27:44 'a different target'? what target? Jan 08 21:30:15 One that I have just made. I call it brcm-2.4-oleg and it basically identical to brcm-2.4 with the exception that LINUX_VERSION is set to 2.4.37.7 and Oleg's patches are applied. Jan 08 21:31:18 hm, no idea why it doesn't apply them Jan 08 21:31:22 but why make a separate target? Jan 08 21:31:39 How else do I maintain a separate set of patches? Jan 08 21:31:52 why not clean up the patches to be included in openwrt? Jan 08 21:31:56 BTW, I am wondering why it DOES apply them. Jan 08 21:32:07 oh, why it does apply them... Jan 08 21:32:11 well, because they're the generic patchset Jan 08 21:32:21 generic patches are always applied Jan 08 21:32:27 But it's specific to 2.4.35 Jan 08 21:32:37 I would like to use 2.4.37 Jan 08 21:32:43 you can create a patches-2.4.37 directory in target/linux/generic-2.4 Jan 08 21:33:02 copy it from the patches/ directory Jan 08 21:33:08 and then fix up the patches with quilt Jan 08 21:33:11 that's the easiest way Jan 08 21:33:36 thanks! And is it going to prevent the application of patches outside of that directory? Jan 08 21:34:11 it always uses *either* patches-$(PATCHVER)/ or patches/, where PATCHVER is the linux version without the trailing sub-version Jan 08 21:34:11 Also, can I set LINUX_VERSION in the profile? Jan 08 21:34:15 no Jan 08 21:34:18 not in the profile Jan 08 21:34:20 iirc Jan 08 21:34:22 or wait Jan 08 21:34:28 you could do a subtarget Jan 08 21:34:36 How does that work? Jan 08 21:34:36 but i don't see much reason for maintaining a separate patchset? Jan 08 21:34:40 why not just upgrade what we have Jan 08 21:34:42 and contribute your changes Jan 08 21:35:53 Because some patches are specific to 2.4.35. Should I identify those and move them to patches-2.4.35 subdirectory? Jan 08 21:38:15 why not just change everything to 2.4.37? Jan 08 21:38:18 instead of splitting it up Jan 08 21:39:22 Wow. So are you suggesting to moving on with the kernel version? That'd be great! Jan 08 21:39:54 there aren't many changes between .35 and .37 Jan 08 21:39:57 so it should be trivial Jan 08 21:40:14 It most probably is. Just a few drivers. Jan 08 21:40:41 There are two backports from the 2.6 branch that I am concerned about. Jan 08 21:41:38 And while we are at it, what should be done about Jan 08 21:41:38 https://dev.openwrt.org/ticket/4083 Jan 08 21:41:38 ? Jan 08 21:42:13 we need proper detection for that, then Jan 08 21:42:26 instead of the hardcoded value Jan 08 21:42:56 But how do you detect a clock rate on a single-clock board? Jan 08 21:43:28 maybe based on nvram parameters or something else Jan 08 21:45:32 I'm wondering why we have all these hardcoded branches for 5354 anyway Jan 08 21:46:02 I think there was just a lazy engineer at broadcom... Jan 08 21:46:32 probably Jan 08 21:51:58 So that said, I wonder what happens if this special case is just removed and we run the normal detection path, Guest89114 Jan 08 21:55:19 nbd: For instance, 202-pl2303_backport.patch is in generic-2.4 patches. It is obsoleted by 2.4.37, because a better backport has been incorporated in the kernel tree. Jan 08 21:55:32 mb__: No idea. Jan 08 21:55:35 Guest89114: then remove it Jan 08 21:55:54 Guest89114: Well, you could just try it ;) Jan 08 21:57:37 What should happen, BTW? What happes on the normal detection path? Jan 08 21:58:16 Well, I don't remember the code. But I think it deduces the freq from various parameters Jan 08 22:00:55 Guest89114: trunk is already using kernel 2.4.37.5 Jan 08 22:02:56 Thanks! I didn't notice that. Jan 08 22:03:34 Then the next thing to check is whether the backport of usb-serial-option is there or not. Jan 08 22:03:40 And add it, if it isn't. Jan 08 22:21:50 Yeah, it was missing, but I added it. Now I'll try to build and run the whole thing. Jan 08 22:44:39 hey guys, i have a quick question Jan 08 22:45:05 how can i get kernel modules to compile in that i select from kernel_menuconfig? Jan 08 22:45:16 i.e. usb_storage etc Jan 08 22:45:27 the KCONFIG line in the kernel module package definition is used to change the kernel config Jan 08 22:45:44 during the target/compile step it rebuilds kernel modules based on the merged config Jan 08 22:46:17 hmm Jan 08 22:46:26 you mean it should compare both configs, and merge them? Jan 08 22:46:48 that's done by scripts/kconfig.pl automatically Jan 08 22:46:52 for each symbol it does this: Jan 08 22:46:57 i mean for each symbol in KCONFIG Jan 08 22:47:12 if it's unset in the kernel config, it gets set to =m Jan 08 22:47:17 if it's set to =y, it's left alone Jan 08 22:47:22 and the package needs to deal with that Jan 08 22:47:49 you can also use KCONFIG to forcibly override values if a package is selected Jan 08 22:47:57 by using =m =n or =y Jan 08 22:48:35 which file are the KCONFIGs in? Jan 08 22:49:25 or where does make_kernelconfig save the configuration to i mean Jan 08 22:50:19 you don't select modules with make kernel_menuconfig Jan 08 22:50:29 okay thats what i was getting at Jan 08 22:50:29 the KCONFIG lines are in the kernel module package definitions Jan 08 22:50:38 ohhhhhh i see! Jan 08 22:50:42 gotcha Jan 08 22:51:04 wait just to make sure i got you correctly Jan 08 22:52:04 whichever kernel modules are available as packages are ignored by the kernel_menuconfig configureation, thats what you meant, right? so i.e. usb storage ehci/uhci/ohci are all available as packages, so whatevere i set in kernel_menuconfig gets ignored Jan 08 22:52:42 welll not ignored by, but the kernel_menuconfig has no effect on what gets compiled, if its defined as a package Jan 08 22:52:45 right? Jan 08 22:55:00 kernel_menuconfig has no effect if you select stuff as =m Jan 08 22:55:05 for =y that's a different matter Jan 08 22:55:42 okay but lets take usb storage as an example Jan 08 22:56:08 right now i had it not selected in menuconfig and =m in kernel_menuconfig Jan 08 22:56:13 yet it didn't get compiled in Jan 08 22:59:20 but i think i got it, let me play around a bit more, and i'll see if i got it right Jan 08 23:33:05 hihi, I have an Infineon Danube card that I'd like to see about getting openwrt onto (or compiling some kernel modules for its existing linux kernel!) Jan 08 23:37:59 a pci card of all things Jan 08 23:38:14 it rocks :) Jan 08 23:38:31 http://www.lex.com.tw/product/images/ADSL2+modem-big.jpg for those not in #openwrt Jan 08 23:38:41 are those caps on the top or jumpers? Jan 08 23:38:50 the 4 on blue ones Jan 08 23:39:15 and it does seem to have a bunch of jumpers atlesat near the connectors Jan 08 23:39:16 ooh, good question. I think caps Jan 08 23:39:35 it has a reset jumper (J2) and a select-ethernet-nic-output jumper (JP7) Jan 08 23:39:46 it's actually in the PC at the moment so getting it out is a bit of a git ;) Jan 08 23:39:48 it seems to have a 4 pin header Jan 08 23:40:13 and next to it, unsoldered pads Jan 08 23:40:24 yeah, I just spotted that Jan 08 23:40:26 is this a kind of doughterboard? Jan 08 23:40:32 a adsl modem I guess Jan 08 23:40:35 ah Jan 08 23:40:36 it's a single-board computer Jan 08 23:40:38 that runs linux Jan 08 23:40:40 it's actually an adsl router Jan 08 23:40:45 cool Jan 08 23:41:05 and you get to choose if it's an ethernet card to the pci bus or to the 4-pin header or to the external ethernt plugsocket Jan 08 23:41:16 and yeah, the unsoldered pads could be seriasl Jan 08 23:41:30 £35 (from linitx.com) makes this thing a bargain :D Jan 08 23:41:43 lupine_85, well, the pinheader could also be it Jan 08 23:41:47 (the 5-pin header is to give it external power) Jan 08 23:41:54 the 4-pin header is an ethernet output Jan 08 23:42:07 oh, ok Jan 08 23:42:11 it differs by the external one by something to do with the transformer Jan 08 23:42:22 the single page of docs wasn't too clear on what Jan 08 23:42:25 you can always try tracing the unconnected pads Jan 08 23:42:48 if they're serial, should they go straight to the infineon chip? Jan 08 23:42:48 and make a educated guess from that Jan 08 23:43:20 or nearly so Jan 08 23:43:26 * lupine_85 is quite badly equipped for this kind of thing Jan 08 23:43:34 one should be ground also Jan 08 23:44:11 and one vref Jan 08 23:45:09 yeah, it might be troublesome for a pci card if you want to be sure you don't break anything Jan 08 23:45:45 lupine_85, umm, there's two white headers on the picture Jan 08 23:45:45 onto a different topic - don't suppose you, or anyone, knows how to pull the linux kernel out of a uboot image? Jan 08 23:45:51 lupine_85, then there's one black plain pin header Jan 08 23:45:55 and one set of 4 pats Jan 08 23:45:57 err.. pads Jan 08 23:46:11 the black pin header is right of the white 4-pin Jan 08 23:46:19 and after that comes the pads Jan 08 23:46:40 then you have a 2-pin header also Jan 08 23:46:52 actually you have 2x 2pin headers Jan 08 23:46:55 mm, the black 4-pin pad is for jumpers selecting whether you use the external ethernet or internal (white 4-pin) ethernet header Jan 08 23:47:02 near the led Jan 08 23:47:07 the 2 2-pin headers we already discussed :) J2, JP7 Jan 08 23:47:23 white 5-pin header is power Jan 08 23:47:23 somehow Jan 08 23:47:52 the danube I have here has two 2pin headers conviniently that enable the bootrom mode Jan 08 23:47:54 I plan on extracting it from my PC and giving it its own 4-port switch via the internal header at some point Jan 08 23:48:13 one of them is a reset header, but that's all I can say about it Jan 08 23:49:24 better resolution pictures might be useful Jan 08 23:49:41 mm, it's not something I can do tonight though :/ Jan 08 23:49:56 curious device certainly Jan 08 23:50:06 I really like it Jan 08 23:50:15 and it comes completely un-locked-down as far as I can see Jan 08 23:50:26 and if you really want to have it usable, I wouldn't mess around it ;P Jan 08 23:50:30 aye Jan 08 23:50:48 I think I might focus on duplicating its toolchain and building kernel modules, perhaps Jan 08 23:51:16 I think blogic has most subsystems on the danube Jan 08 23:51:23 the toolchain isn't a issue Jan 08 23:52:10 well, don't I need to compile kernel modules with the same version of gcc as the kernel? Jan 08 23:52:50 well, I suppose it's preferrable if you want to do that Jan 08 23:52:54 as far as hardware goes, though, I'd call it a prime openwrt device Jan 08 23:53:15 you'd also need the same kernel configuration Jan 08 23:53:38 I wonder how cost effective it is to make a danube into a pci card Jan 08 23:53:38 yeah, they really need to answer my email :D Jan 08 23:53:57 must be cheap to do - this was a steal Jan 08 23:54:12 I guess they saved on a case and a PSU and the like Jan 08 23:54:22 lupine_85, how big is the flash on it? Jan 08 23:55:16 the dumps of the various mtd devices comes to a bit under 4MB Jan 08 23:56:08 not sure how to get a figure from the device itself Jan 08 23:56:52 lupine_85, also does it identify itself as a realtek ethernet? Jan 08 23:57:00 it does, unfortunately Jan 08 23:57:04 that's what the middle chip is Jan 08 23:57:12 yeah, I was looking at it, what a odd device Jan 08 23:57:14 8139cp or 8139too driver Jan 08 23:57:23 Viking do a similar thing but for 3* the price Jan 08 23:58:32 haha, for some reason they compiled their kernel with scsi support Jan 08 23:58:46 probably because of usb storage Jan 08 23:59:08 ie, they were lazy to strip the kernel Jan 08 23:59:13 mm. ok, I have /proc/mtd which gives the sizes of mtd devices 0-6 Jan 08 23:59:36 oh, it's not that important Jan 09 00:00:02 well, it's good to know. plus, it labels them :) Jan 09 00:00:04 does it have chips on the other side of the card also? Jan 09 00:00:09 mtd3 is "Linux" Jan 09 00:00:16 yes, it has a couple of tiny tiny ones Jan 09 00:00:30 can't see them while it's plugged in, of course Jan 09 00:00:43 mtd0 is "U-Boot", 1 is "Environment" Jan 09 00:00:44 mm, albeit the flash might be below the jumpers Jan 09 00:01:43 u-boot eh Jan 09 00:01:50 mine had some weird bootloader Jan 09 00:02:17 * lupine_85 is keeping track of stuff on http://blog.lupine.me.uk/ Jan 09 00:02:24 (just put the mtd stats on tehre) Jan 09 00:03:00 root/admin? :P Jan 09 00:03:17 aye Jan 09 00:03:18 the tradition of good default passwords Jan 09 00:03:34 when I first got it I changed it to my normal password and promptly locked myself out Jan 09 00:03:37 it doesn't like long passwords Jan 09 00:05:05 from a driver sense that card does make quite a bit of sense, from a engineering sense it looks like a mess :P Jan 09 00:05:16 heee, it is rather Jan 09 00:05:39 for doing weird stuff it looks rather nice Jan 09 00:06:15 getting hooked to the serial output might be difficult tho Jan 09 00:06:35 well, if it's that pin header, it won't be so hard Jan 09 00:06:37 I guess you can reboot it from the CLI atleast Jan 09 00:07:14 lupine_85, well, do make sure you don't connect normal serial ports to that Jan 09 00:07:20 ayeaye Jan 09 00:07:20 it might fry your entire pc Jan 09 00:07:36 it'll be being external before I do any real playing about :) Jan 09 00:08:07 I think as long as I don't overwrite th uboot or linux mtd devices, it'll always be resettable to the factory default Jan 09 00:08:08 heh, yeah, that might work Jan 09 00:08:15 if it has external pins for power Jan 09 00:08:19 it does Jan 09 00:08:29 tjhat's the 5-pin header Jan 09 00:08:35 yes, I remember Jan 09 00:09:36 well, I'm sure some people might be amused atleast here by the device, if you mention it earlier in the day :P Jan 09 00:09:40 its busybox: ELF 32-bit MSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked (uses shared libs), stripped Jan 09 00:09:45 weird thing Jan 09 00:10:48 I really /really/ like it Jan 09 00:10:50 :) Jan 09 00:12:16 I really wish I could work out how to unpack this file Jan 09 00:12:26 what file? Jan 09 00:12:45 'file' calls it a u-boot/PPCBoot image Jan 09 00:12:51 it's the linux image Jan 09 00:13:10 it's a uImage Jan 09 00:14:18 uboot mkimage makes those Jan 09 00:14:31 not sure if there's any tool to unpack them Jan 09 00:14:40