**** BEGIN LOGGING AT Wed Feb 11 02:59:57 2009 Feb 11 03:03:33 lol Feb 11 03:03:49 okay... well ordinarily, google is my friend... Feb 11 03:04:56 johnrw: even google can't figure out vista. Feb 11 03:05:38 well i tried and deleted that dialup connection... figuring if it had a trojan... let it connect! Just let it boot too! Feb 11 03:06:36 God I hate Microsoft... and I'm a US citizen... I'm supposed to just Luv Them...(the rest are just commies) :) Feb 11 03:08:44 I am watching director edition of "Bis ans Ende der Welt", I think I will have to watch this a few times to comprehend Feb 11 03:09:57 Wim Wender's original rough cut for this film was twenty hours long ("It will never be seen!"). Feb 11 03:12:32 well... i assume he left the disk 2... back home... but i am going to try Toshiba disk 1... and see what it says... Feb 11 03:17:28 haha... i opted for system restore... and guess what the last restore point is? Feb 11 03:17:43 Windows Update Feb 11 03:42:29 Alright, one more problem, ./configure runs twice when building the package, the second time without my args. This happens after make, which executes: /bin/bash ./config.status --recheck Feb 11 03:42:49 the ./configure.status --recheck runs ./configure again Feb 11 03:56:51 ok... he picked it up... it's out of my hair Feb 11 10:46:59 noz: ping Feb 11 13:28:04 juhosg: so I look closer at Lark's fixsum program, it has some commented code. i write him and ask him where the extra code comes. His response: "My fixsum code is written by analysis of disassemble code. The commented function names Feb 11 13:28:05 and branches are in original httpd. The comment I added is guesswork. I am not sure why size + 0xFE00 and buff + 0x200. There is no firmware update uses this so far." Feb 11 14:53:18 Can someone who knows what the hell they are doing review this :) I want to make sure I'm even picking a linux kernel off the OpenWRT website. http://openwrt.pastebin.com/f60698e63 Feb 11 15:40:13 Ok, to ensure that I am not crazy in files I choose. I do a direct comparison of booting Planex AP81 vs. TP-Link AP81. The one for TP-Link has header.bin added and fixsum run, but still refuses the file that the Planex happily boots. http://openwrt.pastebin.com/f48d8e9f0 Feb 11 15:47:08 florian * r14473 /trunk/target/linux/au1000/ (15 files in 5 dirs): [au1000] prepare to support more au1x00 targets Feb 11 15:48:33 blogic, are you around? Feb 11 16:12:04 florian * r14474 /trunk/target/linux/au1000/au1550/ (config-2.6.27 profiles/ profiles/DBAu1550.mk): [au1000] add DBAu1550 support, thanks to Philippe Vachon Feb 11 16:15:56 juhosg: Lark respond to me and says: The starting kernel message is bogus. This is what I said "just return to u-boot". The boot/bootm/tftpboot will verify kernel image's checksum, and refuse to go on if checksum is not correct. It doesn't freeze, you can continue using u-boot. I did try but not succeed to disassemble u-boot due to limited time. But I guess, using similiar algorithm, the checksum can be deduced using Feb 11 16:17:52 so perhaps the freeze is nothing more than a hang of the decompression code on one vs. other; I had assumed the freeze meant the kernel started... but perhaps on some files it just means the u-boot decompression code fails and maybe goes into a loop. Is another theory. Feb 11 16:36:49 RoundSparrow: i did not find any md5 stuff in the uboot Feb 11 16:46:30 juhosg - then how does running Lark's fixsum allow changes to the rootfs to boot? Feb 11 16:47:27 I think he is making time to look closer, he has a good understanding - might just be best to give him a couple days to see what he figures out - and I'll go back to working on ath9k and such Feb 11 16:48:31 the md5sum is only checked when you upload it via the web interface afaik Feb 11 16:50:03 I will test header without fixsum and see if behaves the same Feb 11 16:50:19 ok Feb 11 16:50:23 by the way, here is the patch for the early debug thing: http://openwrt.pastebin.ca/raw/1334168 Feb 11 16:50:47 the kernel will print a '@' character as soon as possible with this Feb 11 16:50:57 ok, cool Feb 11 16:51:29 you must put this into target/linux/ar71xx/patches-2.6.28 as 999-early-printc.patch for example Feb 11 16:53:40 Ok, thank you, I will try this too Feb 11 17:00:57 ok, and do not forget to run 'make target/linux/clean' Feb 11 17:01:49 yes ;) Feb 11 17:02:46 Lark said of my output: The image should be at least 3 fixed size parts: header, kernel, ramdisk. Every part should not overlap, and every part should be padded to its size if length is not enough. You can't use kamikaze firmware directly. You must split it into kernel and ramdisk image, and do correct padding, then $ cat header.bin kernel.bin ramdisk.bin > wr941n.bin ~~ Using incorrect padding, result is not always Feb 11 17:03:17 But I should be able to boot kernel without disk.. at least get first kernel messages? Feb 11 17:03:38 (That's why I tried it on the Planex just to confirm to myself that I'm doing something reasonable with tftpboot) Feb 11 17:04:18 I think he is not comprehending that tftpboot is not touching flash? Feb 11 17:18:00 juhosg: can you check sanity of this : cat /home/TPLink1/lark/header.bin openwrt-ar71xx-uImage.gz > tplinktry21a.bin Feb 11 17:18:00 That should work, right? but board always says "bad gzipped data" Feb 11 17:20:57 well, this is not a gzipped kernel. this is an u-boot image which contains a gzipped kernel Feb 11 17:22:31 ok, but why does it not fail with "bad gzipped data" when I do this: cat /home/TPLink1/lark/header.bin openwrt-ar71xx-vmlinux.gz > tplinktry22a.bin Feb 11 17:23:32 uImage and vmlinux are both kernels? Feb 11 17:26:57 the uImage is an u-boot specific image, it contains a header like the tplink firmware Feb 11 17:28:32 ah, ok. so that is why it works on the Planex... but on the tp-link the logical thing to do is cat /home/TPLink1/lark/header.bin openwrt-ar71xx-vmlinux.gz > tplinktry22a.bin -- so maybe I try that again with your suggestion of changing the address in the header Feb 11 17:28:37 and the tp-link's u-boot can't handle the original uImage Feb 11 17:30:47 ok, so now I think I understand much better Feb 11 17:31:16 so here is result: you had me change addresses in header - NOW it hangs with those changes. Without changes, it just returns to u-boot. So you are onto something with that address Feb 11 17:32:21 yha, you have convinced me that the fixsum isn't required for u-boot, the issue is only the header Feb 11 17:36:43 This is in reference to your idea: you should try to change the value at 0x78 from 0x80275000 to 0x80060000 in the header.bin Feb 11 17:38:35 juhosg: it comes to my mind that perhaps a single @ from kernel may not show :) remember this u-boot is at 9600bps and I have to switch to 115200. Ok, so where in openwrt do I change the bps rate of kernel? Feb 11 17:39:06 that's usually set by the bootloader Feb 11 17:39:16 console=ttyS0,115200 ect Feb 11 17:39:26 yha, ok, i'll test it Feb 11 17:42:42 well the TP-Link 2.6.15 kernel seems to ignore those params? http://openwrt.pastebin.com/m29f45fda Feb 11 17:43:26 or the uboot loader doesn't set them Feb 11 17:43:44 it is for sure a hacked u-boot ;) Feb 11 17:43:50 bunno how it works on mips, but on arm they're set in the beginning of the memory area Feb 11 17:44:25 you can also set bootargs on the kernel itself Feb 11 17:44:35 ok, where's that in openwrt? Feb 11 17:45:31 dunno, it's CONFIG_CMDLINE="" on kernel .config Feb 11 17:45:33 our kernel don't use the command line parameter passed by u-boot Feb 11 17:46:14 you can change it in trunk/target/linux/ar71xx/config-2.6.28 Feb 11 17:46:24 nodoubt because there's a lack of sane bootloaders :P Feb 11 17:47:03 well almost all vendors in GPL license violiaton for not releasing their u-boot, they all customize it for the LAN chips and such Feb 11 17:47:46 the dns-323 had just everything disabled, they had drivers for lan chips and everything tho :P Feb 11 17:48:04 that uboot has sources available Feb 11 18:02:03 mb * r14475 /trunk/target/linux/generic-2.6/patches-2.6.28/920-01-hotpluggable-spi-gpio.patch: Make spi-gpio hotplug capable, so we can initialize devices after boot. Feb 11 18:03:12 mb * r14476 /trunk/target/linux/generic-2.6/patches-2.6.28/920-02-spi-gpio-without-cs.patch: spi-gpio: Support busses without chipselect (only one device on the bus) Feb 11 18:23:44 RoundSparrow: why do you want to make the .bin? you can tftp uImage and boot it up from u-boot directly Feb 11 18:24:08 normally you need uImage and a rootfs, either in flash or ram Feb 11 18:25:46 under u-boot, you "setenv bootargs root=/dev/ram rw console=ttyS0,115200 init=/etc/preinit" to pass boot args Feb 11 18:25:58 xxiao: 18:28:30 < juhosg> and the tp-link's u-boot can't handle the original uImage Feb 11 18:25:58 because this router u-boot has been sabatoged ;) It requires a binary header Feb 11 18:26:31 xxiao: 18:45:27 < juhosg> our kernel don't use the command line parameter passed by u-boot Feb 11 18:26:48 xxiao: details here: http://download.lark.net.cn/wr941n/hack/ Feb 11 18:26:53 hmmm.... Feb 11 18:27:27 they left a $0.00001 surface mount bridge off the motherboard to make it difficult to get serial port ;) Feb 11 18:27:28 RoundSparrow: with juhosg's help openwrt is booting up well on LS SR71, will send a small patch to Juhosg soon :) Feb 11 18:27:45 cool Feb 11 18:27:57 You are i austin, right? I may go to the ALE meeting tonight Feb 11 18:29:17 yes me at Austin, sorry what's ALE? Feb 11 18:29:17 * juhosg would like an LS-SR71 better :p Feb 11 18:29:51 juhosg: do you do OpenWRT full time? Feb 11 18:30:30 RoundSparrow: not, unfortunately Feb 11 18:30:33 http://ale.freeshell.org/ Feb 11 18:30:53 juhosg: are you in austin :) Feb 11 18:31:02 He is in Hungry ;) Feb 11 18:31:22 wasn't Kaloz also there? Feb 11 18:31:38 RoundSparrow: Hungary precisely Feb 11 18:31:44 sorry ;) Feb 11 18:31:53 my spelling is bad, not a slam on your country ;) Slam on me. Feb 11 18:31:58 guess it's lunch time for RoundSparrow Feb 11 18:33:44 xxiao: yes, Kaloz is from here also Feb 11 18:33:47 RoundSparrow: np Feb 11 18:35:05 juhosg: so the Planex LAN parts, I not try to push you on this as I really appreciate your work. I'm not happy that Planex top selling this in the USA... but anyway, if you focus on other projects - share what you figure out about the LAN port so somebody else might pick up later? Just a unique chip that OpenWRT not use before? Feb 11 18:35:20 (I'm waiting on openwrt to compile to try the TP-Link again) Feb 11 18:35:51 xxiao: I run microblog of Austin stuff: http://Twitter.com/AustinLinux Feb 11 18:37:13 http://mibbit.com/pb/NBZOuH Feb 11 18:38:11 juhosg: can you spot more on the above link? i press the reset button and the value is not chaning Feb 11 18:38:18 s/chaning/changing Feb 11 18:39:57 RoundSparrow: thanks. i'm a follower now Feb 11 18:40:05 claudio * r14477 /packages/utils/strace/patches-4.5.16/010-cris_support.patch: Add cris support in strace Feb 11 18:40:51 RoundSparrow: what do people normally do at ALE? Feb 11 18:45:20 RoundSparrow: we need a driver for ar8216 switch, and i have no datasheet for it yet :/ Feb 11 18:45:28 xxiao: probably it is wired to another gpio line, you can try them all from 0 till 21 Feb 11 18:46:30 xxiao: sit around and work on their computers; not a ton of interaction. Sort of like people in a coffee shop working independently Feb 11 18:48:00 xxiao: see the bottom of this page http://wiki.ubnt.com/wiki/index.php/RouterStation_OpenWRT_SW_Setup_Guide Feb 11 18:51:36 juhosg: that is 2 year old product. Why would Atheros want to not give their source code out for the driver for the switch ;) I assume both AR8216 AR8316 run into this issue. Feb 11 18:51:49 juhosg: thanks for the link! i saw four LEDs, two close to the ST flash chip, two close to the PHY chip Feb 11 18:52:17 without doing anyting, one LED is blinking green Feb 11 18:52:39 the reset buttion never worked for me anyway. Feb 11 18:53:27 i had a classmate working at atheros, but he left one year ago :( Feb 11 18:53:55 otherwise we can get the ar8216 i guess :) Feb 11 18:54:15 hope it's not under NDA though Feb 11 18:56:02 juhosg: testing ethernet piece now... Feb 11 18:56:14 i can think of no reason for Atheros to not release their source code for 2.6.15 / AP81 and the AR8216 or AR8316; they are new to switch market, it would only increase their sales. Feb 11 18:56:53 mb * r14478 /trunk/package/ucmb/ (. Makefile src/ src/Makefile src/ucmb.c src/ucmb.h): ucmb: Experimental SPI-GPIO based communication channel Feb 11 18:57:18 juhosg: so is there really only a single ethernet controller tied to a smart switch? or are there two ethernet controllers, one for WAN and one for switch? Feb 11 18:57:42 I'd probably like to put ucmb into the packages feed, but there doesn't seem to be a directory for kernel modules. Should I create one and move the stuff over? Feb 11 18:58:07 Or is it better to keep all kernel stuff in the base distro Feb 11 19:01:12 RoundSparrow: maybe atheros will disclose it if you request Feb 11 19:03:05 well you know... Feb 11 19:04:46 my friend at atheros once told me that they're a small company and sometimes they did not do certain things until someone else requests Feb 11 19:05:11 Does Atheros distribute GPL stuff? They seem to leave it up to the router sellers (Netgear, Trendnet, etc); but I don't think they put up for download their GPL. Techically they are distributing it (the atheros LSDK [Linux SDK]) to these sellers - they should have to make it available directly. I say this, as once they establish distributing ANYTHING via GPL then it is easier to ask them to add stuff that they choose Feb 11 19:06:34 RoundSparrow: well, we have some source code, but that contains very few informations Feb 11 19:07:07 juhosg: but they are distributing it to trendnet,d-link - they have an obligation to make that available to anyone Feb 11 19:07:19 RoundSparrow: the ar913x contains two ethernet macs, some boards only use one of them, anothers use both Feb 11 19:07:22 not the binary-only drives (not GPL), but the GPL stuff Feb 11 19:08:17 xxiao: i'm guessing that the blinking LED is controlled by the phy chip Feb 11 19:08:26 juhosg: so you already try the 2nd mac and cable in each of the ports? Feb 11 19:10:29 Hi all, I am wondering if anyone can point me to any documentation on how to add a new platform/arch to the build system? Feb 11 19:10:36 welcome to #openwrt-devel! Feb 11 19:10:43 RoundSparrow: yes Feb 11 19:11:01 wrt: thanks Feb 11 19:11:05 juhosg: ok, thanks for the information. will do some thanking Feb 11 19:11:35 haha, do some more digging. Feb 11 19:11:59 RoundSparrow: probably the u-boot initialize the ar8216 differently on the Planex board Feb 11 19:12:18 well as far as I know, Planex has not released GPL at all Feb 11 19:12:34 as they have obligation for u-boot too Feb 11 19:12:41 brb, food Feb 11 19:12:51 that's linked in, so it mean's they can't play the binary module game Feb 11 19:13:00 probably the most important bit is the memory settings the bootloaders do Feb 11 19:14:14 RoundSparrow, dlink has lots of their gpl code available atleast Feb 11 19:15:11 No takers? Feb 11 19:15:31 pitbullpc: have you looked for the question on the mailing list? Feb 11 19:15:32 RoundSparrow, or was that a random selection of mfgs? Feb 11 19:16:16 maligor: my point is that Atheros is clearly _distributing it_ (not just using it internally), so they have GPL obligation Feb 11 19:16:35 ofcourse they distribute it Feb 11 19:16:36 and letting their customers do it (after modifications) does not meet the obligation IMHO Feb 11 19:16:46 RoundSparrow: i have googled, checked the wiki, the forum, and the release docs. nothing in any of those locations that specifically addresses adding a new arch Feb 11 19:16:48 it does Feb 11 19:16:59 gpl only requires you to hand out to the persons you distribute the binary to Feb 11 19:17:16 RoundSparrow: only place I haven't tried is the mailing list Feb 11 19:28:50 RoundSparrow: just searched the mailing list for 'add new platform' and go a wopping 6 hits :) Feb 11 19:29:38 a few good lines of info from Imre, but no doc references Feb 11 19:31:05 Anyone here attend HackNight? Feb 11 19:33:58 Or OpenWRT Weekend prior? Feb 11 19:48:09 So I want to add support for the WL-330gE. It's a standard broadcom sort of device, like the other asus wl-xxx series that are bcm47xx -- 4mb flash, 16mb ram Feb 11 19:48:16 But only one ethernet port, Feb 11 19:48:41 Who wants to help? :P Feb 11 19:51:52 kupesoft: Have you tried just building the bcm47xx arch and seeing if it runs? Feb 11 19:52:32 noz: Picking it up tonight, but I want to add support for it in the diag model and whatever else it needs to be officiall blessed Feb 11 19:52:38 They're nice devices Feb 11 19:52:41 (for what they are) Feb 11 19:52:52 http://priv.kupesoft.com/wl-330ge.jpg Feb 11 19:52:59 s/model/module/ Feb 11 19:53:09 s/module/driver/ :P Feb 11 19:53:35 a 4 in 1 router eh :P Feb 11 19:54:09 juhosg: back? Feb 11 19:54:41 kupesoft, it has a usb ethernet device? Feb 11 19:54:49 kupesoft: I'll be around for a bit of tonight. Have a go, and see what happens Feb 11 19:55:07 maligor: I think SETI uses these for the "Universal Repeater" capability :P Feb 11 19:55:27 maligor: No, just a USB port AFAIK Feb 11 19:55:40 xxiao: yup Feb 11 19:56:05 kupesoft, mm.. yes.. I could do with a optical repeater... "Hey, it doesn't fit!" Feb 11 19:56:29 noz: Alright, I'm assuming it has the failsafe firmware mode that the other Asus routers have, so I can't really frack it up too bad Feb 11 19:56:51 Here's hoping.... Feb 11 19:56:57 Does it have a serial port? Feb 11 19:57:13 kupesoft, well, make sure you make a copy of the full original flash first :P Feb 11 19:57:45 juhosg: looks like i had to hard-code ethernet speed, ag71xx does not have auto-neg in place, at least i failed to find that at drivers/net/ag71xx Feb 11 19:58:17 the PHY of course has an auto-neg bit, but i could not find the code to use that, strange Feb 11 19:58:17 noz: I'd trust a toddler with a soldering iron before me -- not sure though, here's the FCC crap Feb 11 19:58:19 https://fjallfoss.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=N&application_id=936975&fcc_id=%27MSQWL330GE%27 Feb 11 19:59:25 juhosg: http://mibbit.com/pb/4wuDsq Feb 11 19:59:26 all right, midterms, then we play Feb 11 20:00:34 austin is the second worst allergy city in usa, after many years here i'm finally a victim Feb 11 20:00:54 kupesoft, I guess it has serial but no jtag Feb 11 20:01:00 juhosg: all mach-rb4xx.c use the hard-coded phy settings :( Feb 11 20:02:20 xxiao: https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ar71xx/mach-rb-4xx.c#L168 Feb 11 20:02:29 the auto negotiation is handled by the phy layer Feb 11 20:05:33 so you're saying the code i added is fine to LSX? http://mibbit.com/pb/yccyhu Feb 11 20:08:27 nope, see the 'rb411_setup' Feb 11 20:09:15 juhosg: 411 code is the only 4xx code that does not have ethernet working on the LSX :( Feb 11 20:10:00 juhosg: i just tried remove the speed/duplex two lines on LSX code, and the ethernet failed immediately Feb 11 20:11:53 i have have a 411 board here, will try it later Feb 11 20:13:20 xxiao: hmz, the LSX uses a different phy address probably then Feb 11 20:15:38 juhosg: if the phy address is wrong, then manually setting up speed/duplex will still fail, right? but it works here, am i missing sth? Feb 11 20:16:51 juhosg: i also removed gpio/led code from lsx, still works well, as i could not figure out the led/gpio yet. Feb 11 20:17:21 juhosg: the "working" code on LSX for me is at : http://mibbit.com/pb/rp7X5G Feb 11 20:21:32 xxiao: if the phy_mask contains multiple bits, or it is zero, then you have to set the speed and duplex values Feb 11 20:21:41 if it contains only one bit, then the ethernet driver will use that for looking up for a phy Feb 11 20:23:59 <[g2]> nbd how long do I need to be patient on the ixp4xx rc2 first boot ? Feb 11 20:24:10 juhosg: yeah i tried that, phy_mask is 0x6 which worked, but neither 04/02 worked, are you saying i should have removed those speed/duplex two lines when i tried 04 or 02 on phy_mask? Feb 11 20:24:43 i can try to set it to either 04 or 02, while removing those speed/duplex settings Feb 11 20:25:27 you don't need to remove them really, because it is not used in that case Feb 11 20:25:51 juhosg: neither 04 nor 02 worked, let me try one more time Feb 11 20:26:11 maybe you should go through all bits in the phy_mask Feb 11 20:26:33 juhosg: so 9600bps and kernel patch for @ didn't make any difference. Feb 11 20:26:43 RoundSparrow: :/ Feb 11 20:26:45 juhosg: so exactly what is this header doing? Feb 11 20:26:56 juhosg: then how to explain 06 working? hmmm Feb 11 20:28:48 isn't it possible that we tftpboot in a non-compressed kernel and just jump to it with a bootm 0xYYYYYYYYYY address? Feb 11 20:29:40 RoundSparrow: the header contains informations about the kernel and roofts stuff, and the bootm uses this information to find the gzipeed kernel Feb 11 20:29:42 RoundSparrow: bootm will find the entry for uImage, you don't jump to any entrypoints Feb 11 20:30:26 bootm starting-address-of-uImage should just work Feb 11 20:31:21 xxiao: phymask=0 will work also Feb 11 20:31:25 you can make a uimage with just a kernel tho Feb 11 20:31:51 juhosg: let me try 0 nomask then Feb 11 20:32:54 xxiao: with fixed speed and duplex values Feb 11 20:33:11 xxiao: but this u-boot won't start a uImage that a nearly identical router will ;) it is hacked to have a unique header Feb 11 20:33:39 juhosg: understand that. the point is that 0x6 mask works, for single bit, it should either be 0x2 or 0x4, right? but neither works if i don't force speed/duplex Feb 11 20:34:23 isn't this an uncompressed kernel? 4843892 2009-02-11 13:14 openwrt-ar71xx-vmlinux-initramfs.elf Feb 11 20:34:35 RoundSparrow: if we have the u-boot source we can certainly revert those stupid header, totally un=needed, as uImage contains checksum Feb 11 20:35:46 0x6 works because the driver will use the fixed values, and won't check the presence of the phy chip Feb 11 20:36:02 xxiao: i think it's a deliberate attempt to make it difficult Feb 11 20:36:11 do I want the .elf or .bin? Feb 11 20:38:46 juhosg: so you are suggestion i should try phy_mask=0x1,2,4,8,10,20,40,80 without forcing speeding/duplex? i can do that if that's what you mean Feb 11 20:38:46 xxiao: if you are using only 0x2 in the phy_mask, the driver will check the phy chip at phy address 1, and will fail if it is not present Feb 11 20:39:20 xxiao: yeah, exactly Feb 11 20:39:23 juhosg: i though phy_mas=0x6 means it will check phy chip at phy address 1 and 2 (0x04+0x02)? Feb 11 20:39:44 since it worked, i guessed the phy_addr must be either 1 or 2 Feb 11 20:40:23 xxiao: I think it is deliberate attempt to keep people out. The u-boot is modified in wierd ways, and the root has a password Feb 11 20:41:15 RoundSparrow: what exact model are you referring to? i'm going send a fake lawyer letter to ask for u-boot, i owned part of those code anyway :) Feb 11 20:41:26 tl-wr941nd Feb 11 20:41:34 but the release notes ofr the 841 also reference uboot Feb 11 20:42:01 I posted on the u-boot mailing list 2 days ago, no response Feb 11 20:43:52 no, the driver won't check the phy chip at all, if you set multiple bits in the phy_mask Feb 11 20:44:26 xxiao: ^^ Feb 11 20:44:26 juhosg: that's strange, anyone i'm trying all bits now Feb 11 20:44:40 wait a bit Feb 11 20:45:54 change the '0xffffffe9' to '0' in ar71xx_add_device_mdio() Feb 11 20:46:39 xxiao: they official declined u-boot to user in china, for same user they did provide GPL for the main firmware Feb 11 20:47:55 ? someone in china asked u-boot source and was rejected? confused Feb 11 20:47:56 xxiao: and change the '#undef AG71XX_DEBUG' to '#define AG71XX_DEBUG' here: https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/drivers/net/ag71xx/ag71xx.h#L66 Feb 11 20:50:08 juhosg: ok, set mdio to 0 and am trying phy_mask with 0x02, debug is on Feb 11 20:51:05 ok Feb 11 20:52:17 xxiao: a end-user in china, Lark - asked them for u-boot and they refused to provide the source code Feb 11 20:54:49 noz: I don't think I'll be able to get the 330-ge tonight, I'll grab it tomorrow morning. Will you be around then? Feb 11 20:55:14 Not until pm, around 7:30 Feb 11 20:55:35 anyone familiar with the ppc40x build path? Feb 11 20:55:52 mdio=0, phy_mas=0x2, did not work Feb 11 20:56:19 xxiao: dmesg? Feb 11 20:56:38 specifically, what cuImage.magicboxv1 is? Feb 11 20:56:44 noz: Okay, I'll bug you tomorrow about it, unless I can grab it tonight. :) Feb 11 20:56:56 do all 3 images get built? Feb 11 20:59:17 juhosg: http://mibbit.com/pb/UWONkh Feb 11 21:00:22 xxiao: erm, output of the dmesg command Feb 11 21:01:27 RoundSparrow: i believe there is no GPL enforcement in China,so...only Secretary Clinton can press for the code for now :) Feb 11 21:01:42 on the topic of IP infringement etc Feb 11 21:02:59 xxiao: they sell in the USA, so they have legal obligations here Feb 11 21:03:32 RoundSparrow: good point, find the distributor and complain then, i mean loudly Feb 11 21:03:47 RoundSparrow: if the company headquarters is in China, US laws mean nothing Feb 11 21:04:04 customs could confiscate products Feb 11 21:04:11 nope Feb 11 21:05:07 juhosg: http://mibbit.com/pb/TR5NLr Feb 11 21:05:10 not a single AP81 seller includes u-boot source code that I have found, so I think best to complain that it is Atheros issue to communicate down the channel. Atheros is the one getting all the "open source" marketing lately Feb 11 21:05:18 tried 0x1, 0x2, 0x4 without luck Feb 11 21:07:02 RoundSparrow: talk to gpl violation org? Feb 11 21:08:54 http://gpl-violations.org/ Feb 11 21:08:55 xxiao: it does not find any phy chip at all: http://openwrt.pastebin.com/d6f2cc5b0 Feb 11 21:09:29 weird Feb 11 21:09:57 maybe the mdio setting is not right? Feb 11 21:10:50 juhosg: by all means, the driver should default to auto-neg unless i disable it...? Feb 11 21:11:57 yha Feb 11 21:13:23 http://openwrt.pastebin.com/m7de26c18 with phy_mask=0x6, mdio=0x0, with speed/duplex set manually, and it works Feb 11 21:13:45 can anyone explain what a cuImage is? Feb 11 21:14:04 Any PowerPC people in the room? Feb 11 21:14:44 maybe it's a compressed uImage? Feb 11 21:14:48 xxiao: if the driver can't communicate with the phy chip, then it won't be able to do auto-neg Feb 11 21:15:16 pitbullpc: i guess it's compatible uImage, means uImage works without a device-tree-blob, the dtb thing Feb 11 21:15:22 so I think give Lark some time to tinker, he is the one who figured out how to flash these routers. I am going to write Planex (Japan) right now and request GPL download for their u-boot and Linux - they don't have it for what I see, and we hae not figured out the LAN/switch on that router yet. GOOD NEWS, Planex has hem on sale again on Amazon Feb 11 21:15:51 pitbullpc: the nowadays u-boot on powerpc requires a device-tree file, the old one did not, thus cuimage for old u-boot versions Feb 11 21:16:00 xxiao: ok, i think i remember seeing a setting in the kernel config about that. Feb 11 21:16:30 sorry, i have to go, cya Feb 11 21:16:51 juhosg: thanks for all the helps! for me i will stick to the manual settings for now :) Feb 11 21:17:09 xxiao: that makes sense. my u-boot requires the dtb. so i don't need to address cuImages in my target/image/Makefile? Feb 11 21:17:23 or should I include old uboot support? Feb 11 21:18:01 xxiao: ok Feb 11 21:18:12 thank you again Juhosg Feb 11 21:18:26 need get ath0k AP working on LSX now, that is, SR71 Feb 11 21:18:29 ath9k Feb 11 21:18:32 RoundSparrow: you are welcome Feb 11 21:19:56 pitbullpc: let me double check to confirm that Feb 11 21:20:15 xxiao: ok, thanks Feb 11 21:23:51 pitbullpc: if you're using a new u-boot that supports device tree, you do not need cuImage at all, if you're using an older version of u-boot, you do need cuImage, which embeds the device-tree into the kernel image directly Feb 11 21:24:06 mirko * r14479 /packages/Xorg/ (2 files in 2 dirs): adding poc implementation for autostarting x11 applications Feb 11 21:25:32 xxiao: Yes, I have a newer u-boot that takes the dtb. I will leave that out of my new targets Makefile Feb 11 21:26:31 RoundSparrow: i'm begining the journey of ath9k, how good/bad is it from your hands-on exp? Feb 11 21:28:15 bad ;) Feb 11 21:28:27 it isn't getting enough testing and detailed testing reports Feb 11 21:28:43 and the ones recently posted by me and juhosg on ath9k-dev aren't getting a lot of love Feb 11 21:30:17 RoundSparrow: the linux wireless page does state it supports AP mode... Feb 11 21:30:49 juhosg single-handed ported ath9k to the AHB bus routers (AP81), that was only 6 weeks ago... I think only about 10 people are actively working with it ;) I have an Apple Macbook pro and I set it up with the most recent ath9k and it has issues. You can run latest hostapd and under ubuntu Feb 11 21:34:06 RoundSparrow: i have a 9160 minipci on SR71 now, without antennas, my 2.4G pigtail antennas on other minipci cards do not fit, strange Feb 11 21:34:41 guess i need buy those ubnt MIMO pigtails antennas somewhere Feb 11 21:35:07 ok, so PCI bus... although they just had a new stability fix for pci Feb 11 21:35:21 I have to disappear for a couple hours, i'll be around later Feb 11 21:35:24 the MIMO card has a different connector for antennas ,a bit larger than those a/b/g Feb 11 21:40:39 I have a question on block sizes. After looking through several /image/Makefiles I see several different block sizes being specified for dd when converting the uImage. I have seen 64K, 1024K, 1920K, 2048K. What are the driving factors for determining the proper block size to pad the kernel? Flash dependancies? Feb 11 21:58:34 Usually but not always 4MB flash uses 64k blocks and 8MB flash uses 128k Feb 11 22:01:11 Well, all of the block sizes that I have found are evenly divisible by 64K. Seems like the uImage is being padded to 64 or 128K boundaries. Feb 11 22:03:48 Yep (There is one 8MB router that uses 64k block sizes I forget which) Feb 11 22:04:43 What puzzles me is the large range of block sizes. If you use a block size of 1024K and your uImage is 2056K, then I think the image after dd converts it will be 3072K. Feb 11 22:05:55 If you use a block size of 64K, then the image after dd conversion would only be 2112K. Feb 11 22:07:22 Normally the jffs2 is created afterwards taking up the rest of the flash Feb 11 22:07:35 What is the benefit of having such large block sizes like 1024, 1920, 2048? Feb 11 22:10:13 I am thinking that the larger numbers might have something to do with the size of the flash partition allocated for the kernel on different devices. Feb 11 22:10:45 Most of the time I see 2M kernel partitions. Feb 11 22:11:16 and a 2048K block size, i assume would just pad that out. Feb 11 22:11:29 If you have a 64MB flash chip the block size will be much bigger Feb 11 22:12:25 that is true. so you think the numbers that I am finding are directly related to the flash block size? Feb 11 22:13:09 Yep Feb 11 22:15:14 ok, let's look at a concrete example here. trunk/target/ppc44x/image/Makefile Feb 11 22:17:15 now look at Image/Build/jffs2-256K entry Feb 11 22:17:49 the dd uImage with bs=2048K, but dd root with bs=256K Feb 11 22:20:01 i think there is a correlation between the physical flash block size in that the block size that you set should be a multiple of the physical flash block size Feb 11 22:21:01 yep Feb 11 22:21:26 But you want it as small as possible so as not to waste space Feb 11 22:21:34 i agree Feb 11 22:22:28 thanks for the verification Feb 11 23:16:39 mirko * r14480 /packages/Xorg/app/rxvt/ (. Makefile files/ files/icon.png files/rxvt.desktop): adding terminal emulator rxvt Feb 11 23:30:20 mirko * r14481 /feeds/phone/paroli/ (4 files in 3 dirs): upgrade paroli and remove init-script due to prior added generel autostart implementation of x11 applications Feb 12 01:10:00 iperf only showed 27mbps on ag71xx ethernet driver? Feb 12 01:37:50 any xscale wonks around? Feb 12 01:38:36 pardon the repeat from #openwrt but..... Feb 12 01:39:02 on my xscale boards... there seems to be some differences in the NPE... Feb 12 01:39:51 firmware that works great on B stepping units, but on the A stepping...does not see the NPE at all... Feb 12 01:40:16 but the same redboot works on either model. Feb 12 01:41:12 what B/A stepping? Feb 12 01:41:52 ixp422 BB it works... but on ixp42x AB it doesn't Feb 12 01:41:55 have a pronghorn xscale board, did not play with it for a while Feb 12 01:42:25 educate me here...what is BB and AB? Feb 12 01:43:31 ah, that's the cpu revision... AB = rev 0, BB=rev 1... which makes little sense to me but... :) Feb 12 01:44:00 like I wonder... why the 2nd B Feb 12 01:45:06 but noz has a ixp422... AB unit... and I got lucky and landed a ixp425 AB unit... and the support patch for the board only seems to work on BB steppings... Feb 12 01:46:32 which brings a couple of questions... like how to support both revs come to mind... but what I need to learn is how to detect what is different with the wiring of these for the NPE units... Feb 12 02:10:06 hmmm...i believe my pronghorn is a 425, and it just worked with whatever NPE it is Feb 12 02:13:12 I believe this is the latest patch for the board... https://dev.openwrt.org/browser/trunk/target/linux/ixp4xx/patches-2.6.28/500-usr8200_support.patch?rev=13954 Feb 12 02:18:24 johnrw: i do not have the usr8200, i do have a pronghorn metro which is where usr8200's code base Feb 12 02:19:28 well that's close eh... I remember noz saying something about NPE-A being used in these earlier steppings... Feb 12 02:20:29 but did the pronghorn board exist back when these ixp4xx chips were in rev AB would be my next question? Feb 12 02:20:51 ie... does it need code for handling the different revs? Feb 12 02:21:04 usr8200 has no wifi right? it's a wire-based vpn/router/storage device sold for $350, maybe i can develope a powerpc solution :) Feb 12 02:21:41 johnrw: let me check Feb 12 02:22:03 right... no wifi although it was planned... and has the solder pads and trace circuitry Feb 12 02:22:37 I think the power rail was just not installed at the fabhouse... Feb 12 02:24:19 ADI Pronghorn Metro uses B1-step NPEs(ixp425) Feb 12 02:26:20 ok, i'm rewinding my brain, it has been a while since i touched my ixp425 board... Feb 12 02:26:39 on ixp425, we have npe-a npe-b npe-c, and npe-b is used for the ethernet Feb 12 02:30:47 ok i am making a paste of the 2 different bootups... basically the first portion is of the AB that is missing the network... Feb 12 02:31:20 The first lines in the second portion first mention NPE like so.. Feb 12 02:31:22 eth0: MII PHY 16 on NPE-C Feb 12 02:31:22 eth1: MII PHY 9 on NPE-B Feb 12 02:32:02 (we forced eth0 to equal the LAN on this board...) Feb 12 02:37:51 johnrw: the ixp425 on my board has 02 on that, looks like it's made in 2002 Feb 12 02:38:07 not sure the revAB timeline though Feb 12 02:39:14 ah... if you see the chip... on the top line of the etching where it says ixp425 it should have either AB or BB on the end of that... Feb 12 02:41:28 well here's the bootup.. http://pastebin.com/m5b300dc4 Feb 12 02:43:26 the whole thing on the chip is EWIXP425BDT L6220263 02 Feb 12 02:44:54 oh now I see an error msg... amazing how these can escape me Feb 12 02:45:03 == Executing boot script in 3.000 seconds - enter ^C to abort Feb 12 02:45:03 RedBoot> fis load linux Feb 12 02:45:03 RedBoot> exec Feb 12 02:45:03 Using base address 0x00027800 and length 0x00112c54 Feb 12 02:45:03 Uncompressing Linux.......................................................................... done, booting the kernel. Feb 12 02:45:33 shit!!!!!!!!!!!1 Feb 12 02:45:35 sorry guys Feb 12 02:45:45 am i still here? Feb 12 02:46:48 ok well thanks for slood protection... Feb 12 02:46:52 flood* Feb 12 02:47:20 # Feb 12 02:47:21 ixp4xx_eth: probe of ixp4xx_eth.32 failed with error -5 Feb 12 02:47:21 # Feb 12 02:47:21 ixp4xx_eth: probe of ixp4xx_eth.16 failed with error -5 Feb 12 02:49:39 so your problem is that the new 2.6.28 kernel failed to probe eth, while the 2.6.27 did not, Feb 12 02:49:49 but 2.6.27 also said "these are missing" what does it mean Feb 12 02:51:10 Couldn't get a wl-330ge, I drove around the city like a maniac after 7:00pm but the stores I thought would have it were all closed :( Feb 12 02:52:00 oh... did i put these are missing in the wrong spot? Feb 12 02:53:00 oh... i see, I put the these are missing in the output from the kernel that did detect the NPE's correctly Feb 12 02:53:27 ie... those lines are missing in the broken board. Feb 12 02:53:39 ok, so BB stepping is working well, which is an older usr8250, and newer one did not? Feb 12 02:54:11 the BB are later versions... i believe... Feb 12 02:54:54 so what do you want to find out... Feb 12 02:55:03 the newer one works, great then Feb 12 02:55:28 i would expect NPE firmware code handles whatever bug in older steppings already Feb 12 02:55:28 but yeah... the architecture changed enough between the AB and BB so that the kernel misses the AB with an error... Feb 12 02:56:05 by "an error" you mean the ethernet probing error? Feb 12 02:56:11 so would it be that they are using a different numbered phy? Feb 12 02:56:20 yes Feb 12 02:56:38 it could be Feb 12 02:57:07 I think I am going to have to put jungo back in... Feb 12 02:57:42 anyway hope you did "grep" on ixp4xx_eth: probe of ixp4xx_eth.32 failed with error -5 Feb 12 02:57:49 see where the errors is from **** ENDING LOGGING AT Thu Feb 12 02:59:58 2009