**** BEGIN LOGGING AT Tue Aug 03 02:59:57 2010
Aug 03 03:03:07 <RealOpty> LOL
Aug 03 03:03:17 <RealOpty> i suck at the solder
Aug 03 03:03:29 <RealOpty> well at least my tool dose :P
Aug 03 03:03:39 <RealOpty> and speaking of sucking
Aug 03 03:03:48 <RealOpty> i dont have a solder sucker which i need
Aug 03 03:04:30 <RealOpty> cshore, does each line of the jtag need to be grounded?
Aug 03 03:04:37 <CIA-41> jow * r22468 /trunk/target/linux/generic/files/drivers/net/phy/ip17xx.c: ip17xx: r21709 broke VLAN functionality on the IP175C switch, add back mdelay() to wait before reading back the phy state, fixes ethernet on the DIR-300 and possibly others
Aug 03 03:05:02 <RealOpty> the board has grounds under each pin on the board
Aug 03 03:07:39 <cshore> RealOpty: Just connect the grounds on the printer cable to the grounds on the jtag header (just combine them all)
Aug 03 03:08:20 <RealOpty> kk
Aug 03 03:08:24 <RealOpty> ty
Aug 03 03:08:51 <RealOpty> cshore, does it matter what ground on the cable?
Aug 03 03:09:06 <RealOpty> cshore, the info im reading says 20 and 25
Aug 03 03:09:17 <RealOpty> but 18 - 25 are all grounds i think
Aug 03 03:09:36 <xMff> if you want a somewhat universal cable, connect all grounds
Aug 03 03:09:43 <cshore> I would just connect all the grounds (sorry don't remember)
Aug 03 03:09:48 <cshore> what he said :)
Aug 03 03:09:51 <RealOpty> hehehe
Aug 03 03:09:52 <RealOpty> kk
Aug 03 03:09:54 <xMff> sometimes only one pin of the whole row is connected, sometimes all
Aug 03 03:10:12 <RealOpty> i see
Aug 03 06:13:32 <AndyI> hi all!
Aug 03 06:32:57 <acoul> hello
Aug 03 07:36:18 <CIA-41> nico * r22469 /packages/net/appweb/ (Makefile patches/): [packages] appweb: update to 3.2.2-1 (closes: #6979), add dependency on libpthread, cleanup
Aug 03 11:59:02 <CIA-41> nico * r22470 /packages/net/ngrep/Makefile: [packages] ngrep: use PKG_INSTALL, install in /usr/bin instead of /usr/sbin, cleanup, bump release number
Aug 03 11:59:36 <CIA-41> nico * r22471 /packages/net/bind/Makefile: [packages] bind: cleanup
Aug 03 12:04:14 <CIA-41> nico * r22472 /packages/net/quagga/Makefile: [packages] quagga: use PKG_INSTALL
Aug 03 12:07:36 <CIA-41> nico * r22473 /packages/net/stunnel/Makefile: [packages] stunnel: cleanup
Aug 03 12:22:54 <lfcorreia> hi all!
Aug 03 12:23:13 <lfcorreia> looking for the USB driver for ramips platform...
Aug 03 12:23:16 <blogic> aloha
Aug 03 12:23:23 * blogic helps looking
Aug 03 12:23:41 <lfcorreia> blogic: thanks a lot mate!
Aug 03 12:52:38 <stintel> hello all, would anybody be willing to have a look at / comment at the patches for x86 kvm subtarget I sent to openwrt-devel ? thanks
Aug 03 14:05:27 <lfcorreia> ~seen juhosg
Aug 03 15:32:28 <CIA-41> lars * r22474 /trunk/toolchain/gcc/patches/ (4.4.1+cs/910-mbsd_multi.patch 4.4.3+cs/910-mbsd_multi.patch): [toolchain] Add lost handling of -fhonour-copts to 4.4.x+cs/910-mbsd_multi.patch
Aug 03 16:58:36 <dirtyfreebooter> is there an easy way to override CFLAGS? i've tried `CFLAGS="..." make` but it didn't seem to work.. do I have to compile the toolchain with the modified CFLAGS also? I was just doing a make clean
Aug 03 17:25:35 <{Nico}> dirtyfreebooter: you mean override it globally ?
Aug 03 17:45:02 <Memphiz> does anyone have the source code for plparam? it is the tool for the pogoplugs/dockstars to manipulate the u-boot environment ... i would like to compile it for openwrt for using it against the toggling bootloaders *grml*
Aug 03 17:47:08 <Memphiz> otherwise it would be nice to have the flash location of the config (it seems to be embedded in the uboot partition), for using fw_setenv ...
Aug 03 17:54:50 <KanjiMonster> Memphiz: I guess you mean blparam - and it doesn't look good: http://plugapps.com/index.php5?title=Developers:_Pogoplug:_blparam
Aug 03 17:55:19 <Memphiz> ahh of course ... Blparam
Aug 03 17:55:43 <Memphiz> mhh KanjiMonster do you now the flash parameters for using fw_setenv instead?
Aug 03 17:56:16 <KanjiMonster> nope, haven't touched the kirkwood platform yet
Aug 03 17:56:16 <Memphiz> or are there sources of the dockstar uboot somewhere (then we could look into it for getting the config flash info)
Aug 03 17:56:39 <Memphiz> mhh kk ... i'll try some bruteforcing :)
Aug 03 17:56:51 <nbd> do we really need to change the boot loader parameters?
Aug 03 17:57:11 <nbd> ideally I'd like to see the original kernel image replaced by a second stage u-boot
Aug 03 17:57:24 <nbd> and have that provide decent network based recovery
Aug 03 17:57:46 <nbd> that way we can write a simple takeover script that does as little modification to the device as possible
Aug 03 17:58:31 <Memphiz> nbd: by now there is a second uboot bootloader which is jumped into from the original uboot
Aug 03 17:59:22 <Memphiz> but it toggles between boot from nand ™original firmware" and usb ... would be better if it boots from nand on fallback only :(
Aug 03 18:00:17 <KanjiMonster> Memphiz: I haven't found them yet, but th pogoplug's u-boot sources are available: http://download.pogoplug.com/opensource/pogoplug-u-boot-1.1.4.tgz
Aug 03 18:00:30 <Memphiz> thx
Aug 03 18:02:33 <nbd> why boot from nand as fallback only?
Aug 03 18:02:39 <nbd> it would be nice if we could just install openwrt to the nand
Aug 03 18:02:39 <nbd> imho
Aug 03 18:05:30 <Memphiz> nbd: by now my device is note altered in any way ...
Aug 03 18:05:40 <Memphiz> i mean
Aug 03 18:06:04 <Memphiz> its easy reversible to factory ... without reflashing (just setting 2 parameters in uboot and deleting the second uboot)
Aug 03 18:06:33 <Memphiz> it is possible to install openwrt on the nand afaik ... but i find it sweeter that the second uboot boots direct from usb ...
Aug 03 18:07:32 <nbd> we should definitely support both
Aug 03 18:07:45 <Memphiz> it is i think ...
Aug 03 18:07:56 <nbd> just not properly integrated yet
Aug 03 18:08:07 <KanjiMonster> I would even say installing openwrt to the nand would be the normal case
Aug 03 18:08:12 <nbd> yes
Aug 03 18:08:24 <Memphiz> but the dockstar has a nice socket for 2,5" hdd driver
Aug 03 18:08:26 <Memphiz> -r
Aug 03 18:08:37 <nbd> not everybody has a drive for it
Aug 03 18:08:38 <Memphiz> and so i used it ;o)
Aug 03 18:08:45 <Memphiz> yeah your right
Aug 03 18:08:56 <Memphiz> of course the normal approach would be like with all other routers ... full ack
Aug 03 18:09:02 <nbd> I think for deploying (and updating) a device, it should work like this:
Aug 03 18:09:20 <nbd> When you build openwrt, you get an image that you can dd to a usb flash drive
Aug 03 18:09:28 <nbd> you put that in the device, let it boot from that
Aug 03 18:09:29 <Memphiz> and thats why i want to modify the uboot params from within openwrt ... its would be a dirty little workaround for my prob ;)
Aug 03 18:09:51 <Memphiz> wow ... that would be great!
Aug 03 18:09:56 <nbd> then you can import the config from the running device into the usb drive if you want to
Aug 03 18:10:07 <nbd> and if everything works, you can tell it to copy all the data from the usb drive to the nand flash
Aug 03 18:10:13 <nbd> and then let it boot from nand
Aug 03 18:10:26 <Memphiz> hrhr ... thats desktop like ;)
Aug 03 18:10:37 <Memphiz> of course one could use elinks and surf the net while installing to nand ;)
Aug 03 18:10:55 <nbd> or here's another idea
Aug 03 18:11:05 <RealOpty> Hauke,
Aug 03 18:11:05 <nbd> the chainloaded uboot gets http upload support for uimages
Aug 03 18:11:07 <RealOpty> ping
Aug 03 18:11:17 <nbd> you use your browser to upload an installer uImage
Aug 03 18:11:25 <nbd> and it just installs itself
Aug 03 18:11:30 <Memphiz> apropos nbd ... a first step would be to have an kexec kernel target (which adds lets one modify the cmdline) :D ...
Aug 03 18:12:03 <Memphiz> nbd: i think your theory is very nice ... but its much work i think ...
Aug 03 18:12:04 <nbd> not a strict requirement for this, but yes, it would be useful
Aug 03 18:12:49 <nbd> the problem with the cmdline stuff is we cannot just accept a random cmdline from the boot loader
Aug 03 18:13:00 <nbd> since more often than not, the cmdline provided by the boot loader is broken
Aug 03 18:13:24 <Memphiz> we only need the user changable cmdline for kexec ...
Aug 03 18:13:37 <Memphiz> but nobody should try to flash this kernel somehow ...
Aug 03 18:14:02 <RealOpty> Hauke, i have jtag working on the router now :) so yeah lets break this thing :P
Aug 03 18:14:24 <Memphiz> nbd or not really changable
Aug 03 18:14:28 <RealOpty> well i already broke it, fixed it and broke it again.
Aug 03 18:15:03 <Memphiz> there could be some fixed values (BOARD=TL-1043ND, rootfsdelay=10, noinitrd ) ... and the user only could select the rootdevice and rootfstype
Aug 03 18:15:31 <RealOpty> Hauke, in order to flash this device, the 'rootfs' of the firmware has to be smaller than 1.5mb.
Aug 03 18:15:45 <Memphiz> board=TL-WR1043ND noinitrd console=ttyS0,115200 root=/dev/sda1 rootdelay=10 rootfstype=ext2 <- thats mine kexec cmdline ... and only sda and ext2 must be changable imho
Aug 03 18:16:06 <nbd> rootdevice and rootfs type is the thing in the boot loader command line that most frequently contains garbage
Aug 03 18:16:19 <nbd> so we need a way for the kernel to tell apart kexec cmdline from boot loader cmdline
Aug 03 18:16:26 <nbd> because i think they're passed to the kernel in the same way
Aug 03 18:16:39 <Memphiz> yes ... why not compile it in like now?
Aug 03 18:16:54 <Memphiz> and build 2 kernels (one for the flash and one for kexec)
Aug 03 18:17:07 <builder> build #62 of ubicom32 is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/62
Aug 03 18:17:31 <nbd> i'd like to avoid building two kernels in one iteration
Aug 03 18:17:52 <Memphiz> nbd ... or just give it a flag ... if the flag is not present we assume cmdline comes from the bootloader and treat it as broken (using the fixed one) ... if flag is set - it comes from kexec and wie use the cmdline
Aug 03 18:18:14 <Memphiz> something like force_user_cmdline=1 or so ...
Aug 03 18:18:22 <nbd> patches welcome ;)
Aug 03 18:18:25 <Memphiz> damn
Aug 03 18:18:26 <Memphiz> :)
Aug 03 18:18:35 <Memphiz> mhhh
Aug 03 18:18:48 <Memphiz> it has to be around the cmdline fix right?
Aug 03 18:19:56 <Memphiz> arpropos patches ... i've managed to pick out the last syntax error in the rtl8366xx patch (there was still one return missing) ... i've attached it to the bug again ... or should i send the patch by mail? (don't know how the workflow is better for you)
Aug 03 18:20:34 <nbd> the attachment is enough
Aug 03 18:21:43 <Memphiz> uhh the cmdline hack looks absolutly non understandable on the first sight *g*
Aug 03 18:22:06 <Memphiz> its a compile hack ... we would need a runtime hack ...
Aug 03 18:22:44 <nbd> you could add a patch to kexec that overwrites the memory used by the cmdline hack
Aug 03 18:22:55 <nbd> ;)
Aug 03 18:23:07 <Memphiz> hrr
Aug 03 18:23:16 <Memphiz> but what if the cmdline gets longer then before?
Aug 03 18:23:18 <Memphiz> ^^
Aug 03 18:23:22 <nbd> that's fine
Aug 03 18:23:27 <Memphiz> really?
Aug 03 18:23:28 <nbd> the cmdline hack uses a fixed buffer size
Aug 03 18:23:32 <Memphiz> ahh ...
Aug 03 18:23:33 <nbd> because it's patched by the build process
Aug 03 18:27:09 <Memphiz> mhh
Aug 03 18:27:13 <KanjiMonster> mh, somehow the ar8216 driver got miscredited to me
Aug 03 18:27:20 <RealOpty> nbd, does the openwrt-brcm47xxx.TRX have the headers stripped out?
Aug 03 18:28:03 <nbd> it has the trx header
Aug 03 18:28:06 <nbd> as the name implies
Aug 03 18:28:24 <RealOpty> kk im no expert :p dont bite
Aug 03 18:28:42 <RealOpty> nbd, how do i generate a image with out headers?
Aug 03 18:28:52 <nbd> i don't bite
Aug 03 18:29:01 <nbd> the trx header is required, you cannot build a broadcom image without it
Aug 03 18:29:44 <RealOpty> hmmm. this device is so weird, its a pain in the ass lol
Aug 03 18:30:01 <RealOpty> it dont wanna accept any image over tftp other than its own.
Aug 03 18:30:03 <Memphiz> nbd ... do you mean patching the userspace side or the kernel side of kexec ...
Aug 03 18:30:09 <nbd> Memphiz: user space side
Aug 03 18:30:24 <Memphiz> k
Aug 03 18:30:31 <nbd> or maybe not
Aug 03 18:30:39 <nbd> maybe just packaging the cmdline patch utility
Aug 03 18:30:43 <nbd> and making it work with elf headers
Aug 03 18:31:00 <nbd> then we wouldn't need any patching
Aug 03 18:31:04 <nbd> of other packages
Aug 03 18:31:06 <Memphiz> that would be great
Aug 03 18:31:13 <Memphiz> how is the tool called
Aug 03 18:31:36 <nbd> it's in tools/patch-cmdline
Aug 03 18:32:08 <Memphiz> i'll try that i think
Aug 03 18:32:19 <Memphiz> first making a package of course ... should be straight forward
Aug 03 18:33:45 <nbd> actually... maybe it already works with elf images
Aug 03 18:33:47 <nbd> worth a try
Aug 03 18:33:53 <Memphiz> nbd ... but when we make the patch-cmdline tool work on openwrt ... and use it there ... this could be handled while building aswell
Aug 03 18:34:12 <Memphiz> because the image needs to be patched only once ...
Aug 03 18:34:23 <nbd> yes, you can change the cmdline on the host as well
Aug 03 19:03:15 <netprince> Is anyone else having trouble building brcm47xx?  http://openwrt.pastebin.com/SN2FaZpu
Aug 03 19:10:11 <RealOpty> netprince, have you been using svn?
Aug 03 19:10:30 <netprince> yes, this is 22476
Aug 03 19:11:30 <RealOpty> try making a new folder and do a completly new setup. (this helped me the other day)
Aug 03 19:11:45 <netprince> 22467, sorry
Aug 03 19:11:55 <netprince> ok, will try that
Aug 03 19:12:03 <RealOpty> idk if i broke the build_dir or if svn up did
Aug 03 19:12:12 <RealOpty> but a freash start and no problems :/
Aug 03 19:12:23 <RealOpty> fresh *
Aug 03 19:17:57 <Memphiz> mhh nbd how can i get the build system pickup the new package ...
Aug 03 19:18:07 <Memphiz> thought this was done automagically some time before?!?
Aug 03 19:18:28 <nbd> if you throw a package directory in to the package/ folder, it will be picked up by the build system
Aug 03 19:18:32 <nbd> run make oldconfig to be able to select the package
Aug 03 19:29:25 <Memphiz> "ERROR: please fix package/patch-cmdline/Makefile" <- mhh not as exact as i wanted *g*
Aug 03 19:37:41 <Memphiz> *sigh* ... nbd could you have a look please? (its not my first package, but i don't see the issue here ...)
Aug 03 19:37:41 <Memphiz> http://pastebin.com/wc9Lxuu0
Aug 03 19:39:33 <cshore> Is there a reason line 32 doesn't have <-------> and the others do?  I presume it the tab?
Aug 03 19:40:40 <cshore> you also have no description
Aug 03 19:40:56 <cshore> sorry. long description
Aug 03 19:41:34 <cshore> define Package/freeswitch-config-minimal/description
Aug 03 19:41:34 <cshore>  for instance
Aug 03 19:47:20 <Memphiz> ahh thx cshore
Aug 03 19:47:48 <Memphiz> this fuckin bastard midknight commander ... his editor has a <----> for tab indication ... and it was a copy paste (and it pasted the <----> as ascii into *grml*)
Aug 03 19:48:35 <Hauke> RealOpty: pong
Aug 03 20:06:00 <nbd> Memphiz: good thing it did, because that made it easier to spot the bug ;)
Aug 03 20:07:48 <Memphiz> nbd: nope i hate that feature ... it wasn't so in older versions ... if i go on the line start when editing there is no cursor ... nobody knows in which line it will edit next ;)
Aug 03 20:09:03 <Memphiz> root@Gateway:~# patchcmdline
Aug 03 20:09:03 <Memphiz> Usage: patchcmdline <file> <cmdline>
Aug 03 20:09:08 <Memphiz> ^^...
Aug 03 20:09:17 <Memphiz> have to test if it will eat elf kernel
Aug 03 20:30:49 <Memphiz> nbd is patch-cmdline your work?
Aug 03 20:30:56 <nbd> partially
Aug 03 20:31:24 <nbd> actually, the tool is mine
Aug 03 20:31:31 <nbd> but the kernel part was made more generic by juhosg, iirc
Aug 03 20:33:13 <Memphiz> mhh make tools/patch-cmdline/{clean,compile,install} should regenerate it in build_dir/host isn't it?
Aug 03 20:33:24 <[Fate]> hi. I've the surprising effect that my tp-wa901nd has stopped working with the network config which used to work all the time before :)
Aug 03 20:33:36 <[Fate]> tftp works, original firmware works, so cabling is all right
Aug 03 20:34:01 <[Fate]> it seems as if my network setup code in mach-tl-wa901nd.c is not correct yet
Aug 03 20:35:58 <CIA-41> hauke * r22475 /trunk/target/linux/brcm47xx/ (2 files in 2 dirs):
Aug 03 20:35:58 <CIA-41> brcm47xx: ignore some parts of flash on some netgear devices. This
Aug 03 20:35:58 <CIA-41> space is used to store config values. When overwriting it the device
Aug 03 20:35:58 <CIA-41> will not start any more.
Aug 03 20:35:58 <CIA-41> closes #7630
Aug 03 20:35:58 <CIA-41> Thank you realopty for testing.
Aug 03 20:37:07 <RealOpty> just got back :)
Aug 03 20:37:28 <RealOpty> Hauke, you gonna be online for a bit?
Aug 03 20:37:32 <cshore> RealOpty: hauke just comitted the netgear thing
Aug 03 20:37:50 <Hauke> RealOpty: no not thant long any more
Aug 03 20:40:13 <RealOpty> Hauke, i need to do some more testing. I first though that the patch had actually deleted some of the board data. but it seems as if dd-wrt had caused the mac problem. I havent had the chance to confirm yet.
Aug 03 20:40:44 <RealOpty> this thing is a pain in the ass to flash...
Aug 03 20:41:10 <RealOpty> first you have to have the stock firmware, then dd-wrt, then flash openwrt...
Aug 03 20:41:28 <RealOpty> and even then sometimes dd-wrt dont wanna flash the image, so i have to do it from command line
Aug 03 20:41:31 <Memphiz> nbd: may i patch it in the following way? If only one arg is given, treat it as image filename and just printout the found cmdline? (so i can adapt my kexec script in openwrt to change the cmdline only if it isn't already done ... e.g. for new kernels)
Aug 03 20:41:44 <nbd> sure
Aug 03 20:42:08 <Memphiz> it works with elf files btw if the mmap space is increased to 100k (65k would also work ... but be on the save side)
Aug 03 20:42:16 <RealOpty> Hauke, so if i confirm that the patch isnt working then ill have someone revert the changes if your gone :)
Aug 03 20:43:11 <RealOpty> Hauke, in order to flash openwrt from stock firmware we need a .chk style image. any tips on this?
Aug 03 20:43:12 <Hauke> RealOpty: what does: "nvram show |fgrep mac" print out?
Aug 03 20:43:41 <RealOpty> Hauke, its running stock firmware atm, so i dont have the chance to do that just yet
Aug 03 20:43:52 <nbd> Memphiz: ok
Aug 03 20:44:10 <RealOpty> Hauke, but after fixing the router and doing more testing lastnight the mac addr was correct for lan and wan
Aug 03 20:44:18 <Hauke> RealOpty: to generate a .chk file you have to use packet
Aug 03 20:44:29 <RealOpty> i believe that dd-wrt broke it when i told it to flash the image and reset nvram vars.
Aug 03 20:44:42 <Hauke> RealOpty: could be
Aug 03 20:45:56 <RealOpty> but yeah i just got some dsub connectors and im gonna fix up the poor jtag job i did  :) then get back to testing :P
Aug 03 20:47:52 <RealOpty> Hauke, the tftpd server on the CFE is really sensitive to what it wants to accept. and really tricky to make work :/
Aug 03 20:49:33 <RealOpty> but lastnight i tried to use the b43 driver with the wifi but it didnt detect it. (nor did the broadcom binary)
Aug 03 20:50:47 <RealOpty> another weird thing is that the 'wan' port gets an IP but it dont allow any communication
Aug 03 20:51:02 <RealOpty> i think it might be a config/network problem with vlan
Aug 03 20:51:40 <Hauke> RealOpty: ir could be that openwrt could not read out the nvram correctly
Aug 03 20:52:13 <RealOpty> any suggestions on what to look for?
Aug 03 20:53:04 <RealOpty> hmm it could be cause dd-wrt does change some nvram vars too
Aug 03 20:53:35 <Memphiz> nbd
Aug 03 20:54:28 <Memphiz> my approach doesnt work
Aug 03 20:54:40 <Memphiz> the patch-cmdline tool looks for "CMDLINE:" and treats it as string
Aug 03 20:55:06 <Memphiz> but the CMDLINE which is patched in is not on at this point ...
Aug 03 20:55:14 <Memphiz> whats the deal here
Aug 03 20:55:50 <Memphiz> so i allways read "" there because the CMDLINE: field is empty ...
Aug 03 20:58:36 <russell_> Hauke: i don't see wgt634u problems addressed in the latest commit
Aug 03 21:00:46 <Hauke> russell_: no that problem is not addressed with taht patch
Aug 03 21:00:48 <Memphiz> nbd or does the cmdline which is behind "CMDLINE:" override the hacked cmdline in some way?
Aug 03 21:02:15 <russell_> i'm slightly curious why we are writing to that erase block at all
Aug 03 21:02:29 <builder> build #63 of xburst is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/xburst/builds/63
Aug 03 21:02:30 <russell_> is it just to squeeze out some more space?
Aug 03 21:03:13 <Hauke> russell_: no these devices to not like it when some parts of the falsh are overwritten
Aug 03 21:03:59 <russell_> right, that's the problem i'm having on the wgt634u
Aug 03 21:04:57 <russell_> it sounds like the same problem, anyway
Aug 03 21:05:19 <nbd> Memphiz: showm e the code
Aug 03 21:05:55 <Memphiz> nbd it is nothing in the code
Aug 03 21:06:10 <nbd> in the ELF image, the CMDLINE: part is likely to be empty
Aug 03 21:06:11 <Memphiz> look at a binary build from the buildroot and search for "CMDLINE:" and then for "ttyS0" ...
Aug 03 21:06:18 <Memphiz> in binary it is equal
Aug 03 21:06:51 <nbd> the part after CMDLINE: is only added for the cmdline-patched images
Aug 03 21:07:01 <nbd> not in the elf images that the kernel tree builds
Aug 03 21:07:51 <Memphiz> after CMDLINE: is nothing ... in binary also
Aug 03 21:08:01 <Memphiz> maybe i'm looking in the wrong file?
Aug 03 21:08:19 <Memphiz> i find the cmdline in both, elf and binary, near the end of the file
Aug 03 21:08:34 <Memphiz> and CMDLINE: is in the first 100KB ... bat nothing afterwards
Aug 03 21:09:52 <Memphiz> strings openwrt-ar71xx-generic-vmlinux.bin | grep -n CMDLINE
Aug 03 21:09:52 <nbd> odd
Aug 03 21:09:52 <Memphiz> 1:CMDLINE:
Aug 03 21:09:56 <Memphiz> strings openwrt-ar71xx-generic-vmlinux.bin | grep -n ttyS0
Aug 03 21:09:56 <Memphiz> 18555:board=TL-WR1043ND rootfstype=ext3 noinitrd console=ttyS0,115200 root=/dev/sda1 rootdelay=10
Aug 03 21:10:02 <Memphiz> see what i mean?
Aug 03 21:10:46 <russell_> Hauke: in the last 0x20000 sized erase block on the flash part, at offset 0x1e000 there is the information CFE uses to boot.  you can access the information from CFE with the printenv and setenv commands.
Aug 03 21:11:09 <Hauke> ah
Aug 03 21:11:20 <nbd> Memphiz: ah
Aug 03 21:11:28 <Hauke> I will look at it in the nextdays
Aug 03 21:11:30 <nbd> Memphiz: you told me you changed your configured cmdline
Aug 03 21:11:37 <nbd> Memphiz: and put the board= part in therek
Aug 03 21:11:53 <nbd> the patched cmdline is only used for the board= stuff at the moment
Aug 03 21:11:55 <nbd> not for the full cmdline
Aug 03 21:12:35 <Memphiz> nbd: i tried this on an untouched trunk for my fonera ... same thing there
Aug 03 21:12:44 <russell_> Hauke: there is some other information (not sure what uses it) at 0x18000
Aug 03 21:12:55 <nbd> Memphiz: i just did a hexdump and it shows this:
Aug 03 21:12:56 <nbd> 00000400  00 00 00 00 00 00 00 00  00 00 00 00 43 4d 44 4c  |............CMDL|
Aug 03 21:12:59 <nbd> 00000410  49 4e 45 3a 62 6f 61 72  64 3d 55 42 4e 54 2d 52  |INE:board=UBNT-R|
Aug 03 21:13:02 <nbd> 00000420  53 50 52 4f 00 00 00 00  00 00 00 00 00 00 00 00  |SPRO............|
Aug 03 21:13:06 <nbd> this is the vmlinux binary for the rspro (uncompressed, not elf)
Aug 03 21:13:18 <Memphiz> ahh so everything which i write behind CMDLINE will be added
Aug 03 21:13:21 <Memphiz> right?
Aug 03 21:13:32 <Memphiz> now its clear what happens i think
Aug 03 21:13:39 <Memphiz> but it isn't usable for kexec in that way :(
Aug 03 21:13:51 <Memphiz> but nevertheless the patch and package are ready ;)
Aug 03 21:15:19 <Memphiz> and on my fonera there is a elf kernel only ... thats the cause why it is empty there too ...
Aug 03 21:15:21 <Memphiz> mhh
Aug 03 21:15:41 <Memphiz> Bummer!
Aug 03 21:16:48 <nbd> try using it to override variables
Aug 03 21:16:54 <nbd> maybe that'll work
Aug 03 21:16:54 <nbd> not sure
Aug 03 21:17:23 <Memphiz> i'll try
Aug 03 21:17:48 <Memphiz> but as i see the vars are before the original vars ... so when overriding works ... it will override in the wrong direction ... but i'll try
Aug 03 21:25:23 <RealOpty> does any one think that putting a connector for jtag and serial next to the wifi antenna is a bad idea?
Aug 03 21:29:24 <[Fate]> nbd: r22401 breaks my ar7240 device
Aug 03 21:29:30 <[Fate]> for some reason
Aug 03 21:32:17 <nbd> can't be
Aug 03 21:32:27 <nbd> it changes a function that is never called for your device
Aug 03 21:32:37 <nbd> if you're talking about the tl-wa thing
Aug 03 21:32:46 <[Fate]> I know, that's the strange thing
Aug 03 21:33:51 <[Fate]> but I did make clean between updating to r22400 resp. r22401
Aug 03 21:34:28 <nbd> odd
Aug 03 21:38:33 <Memphiz> testing override ... brb
Aug 03 21:41:37 <Hauke> RealOpty: I will leave now
Aug 03 21:46:08 <Memphiz_Away> nbd "Kernel command line:  board=TL-WR1043ND rootfstype=ext2 rootdelay=10 root=/dev/sda1 rootfstype=squashfs,yaffs,jffs2 noinitrd console=ttyS0,115200" <- does not work :( ... it panics ... it can't mount wether sda1 nore mtd ...
Aug 03 21:46:31 <Memphiz_Away> patching of cmdline works as expected though
Aug 03 21:50:16 <KanjiMonster> Memphiz_Away: btw, I can't find an dockstar gpl tarball, but there is one for the goflex, which is mostly the same hardware (at least SoC wise): http://www.seagate.com/staticfiles/support/downloads/opensource.goflexhome.gm1.tar.bz2
Aug 03 21:51:07 <Memphiz> KanjiMonster: thx ...
Aug 03 22:13:10 <Memphiz> nbd: did you get mail from me?
Aug 03 22:13:28 <nbd> yes
Aug 03 22:14:07 <nbd> thx
Aug 03 22:14:08 <Memphiz> :D
Aug 03 22:15:26 <Memphiz> KanjiMonster: the fscking download always gets interrupted ... if this is intentional? *G*
Aug 03 22:16:20 <KanjiMonster> Memphiz: i don't think so - it downloaded fine here
Aug 03 22:16:37 <Memphiz> 460mb right?
Aug 03 22:16:43 <KanjiMonster> yes
Aug 03 22:17:21 <Memphiz> mhh
Aug 03 22:17:28 <Memphiz> trying the third time now
Aug 03 22:17:50 <Memphiz> note to myself don't use trunk of ath9k when downloading big files ;o)
Aug 03 22:18:05 <KanjiMonster> resume doesn't work?
Aug 03 22:20:48 <Memphiz> mhh firefox doesn't in this case
Aug 03 22:21:03 <nbd> Memphiz: is this a regression?
Aug 03 22:22:00 <Memphiz> nbd mhh i don't think so ... i don't hope so ... haven't any evidences ... will have an eye on it but maybe it is just my provider or somthing ... there are no errors in my logs though
Aug 03 22:22:35 <nbd> because based on the feedback i got so far, the ath9k version in trunk should be more stable than all previous versions
Aug 03 22:23:08 <nbd> and if there's still a serious bug in there, i need to know about it
Aug 03 22:23:57 <Memphiz> of course ... don't worry, i will blame you when i have to ... my internet is dependend on the ath9k :)
Aug 03 22:24:31 <KanjiMonster> Memphiz: use wget ;)
Aug 03 22:24:45 <Memphiz> yes i will do this when it cuts off again
Aug 03 22:24:54 <Memphiz> i've got 33%  now
Aug 03 22:26:07 <Memphiz> KanjiMonster: i've gotten fw_printenv to work on dockstar ... but i had to comment the crc check in sourcecode :(
Aug 03 22:26:21 <Memphiz> cat /etc/fw_env.config
Aug 03 22:26:28 <Memphiz> /dev/mtd0               0xA0000          0x1FFFC          0x20000
Aug 03 22:26:30 <Memphiz> there it is
Aug 03 22:26:34 <Memphiz> it prints the env ...
Aug 03 22:26:40 <Memphiz> but crc checking doesn't work mhh
Aug 03 22:28:43 <Memphiz> mhh will do some printouts and search for the right crc ...
Aug 03 22:28:50 <Memphiz> maybe i find something ...
Aug 03 22:36:31 * Memphiz thinks of an endianess problem ...
Aug 03 22:38:08 <Memphiz> expected crc: 11028A08, got: 50D42BD5 mhh wtf ...
Aug 03 22:38:58 <KanjiMonster> Memphiz: the tarball contains an separate "fw_printsetenv" source rpm
Aug 03 22:39:14 <Memphiz> ahh
Aug 03 22:39:16 <Memphiz> i got it
Aug 03 22:39:23 <Memphiz> my size was 4 bytes to short
Aug 03 22:39:30 <Memphiz> expected crc: 50D42BD5, got: 50D42BD5
Aug 03 22:39:46 <Memphiz> /dev/mtd0               0xA0000          0x20000          0x20000
Aug 03 22:39:51 <Memphiz> thats the right config
Aug 03 22:41:40 <Memphiz> mhh should i try to modify it? ^^
Aug 03 22:41:50 <Memphiz> but its so late *grml*
Aug 03 22:43:39 <Memphiz> well i've to go to bed ...
Aug 03 22:43:49 <Memphiz> good night
Aug 04 00:43:45 <CIA-41> nbd * r22476 /trunk/target/linux/generic/ (11 files in 6 dirs):
Aug 04 00:43:45 <CIA-41> swconfig: cleanup of kernel drivers and interface
Aug 04 00:43:45 <CIA-41> - add some comments to a few data structures
Aug 04 00:43:45 <CIA-41> - add a switch_dev_ops data structure for attributes and callback to replace the stupid template memcpy
Aug 04 00:43:45 <CIA-41> - get rid of the switch_dev.priv pointer - using container_of() is better
**** ENDING LOGGING AT Wed Aug 04 02:59:57 2010