**** BEGIN LOGGING AT Sun Sep 12 02:59:57 2010
**** BEGIN LOGGING AT Sun Sep 12 04:52:32 2010
Sep 12 06:14:27 <builder> build #110 of brcm63xx is complete: Failure [failed compile_10]  Build details are at http://tksite.gotdns.org:8010/builders/brcm63xx/builds/110
Sep 12 07:05:39 <builder> build #77 of ubicom32 is complete: Failure [failed compile_4]  Build details are at http://tksite.gotdns.org:8010/builders/ubicom32/builds/77
Sep 12 11:08:45 <Memphiz> larsc: are you there? *ping*
Sep 12 11:09:02 <Memphiz> i've tried to install your 2nd stage u-boot bootloader on dockstar ...
Sep 12 11:09:46 <CIA-57> mb * r23027 /trunk/package/iproute2/patches/ (6 files): iproute2: Add lex/yacc files dependencies. Refresh other patches.
Sep 12 11:09:53 <Memphiz> but where does it access the env? i get an crc error when starting the bootloader and it fills the env with default values ... in the wiki there isn't mentioned anything about the env...
Sep 12 11:17:33 <Memphiz> and by the way ... the generated u-boot binary has to be page aligned (dd if=uboot.bin of=uboot-aligned.bin bs=128k conv=sync)
Sep 12 11:17:42 <Memphiz> this should be done somewhere in the makefile
Sep 12 11:17:48 <Memphiz> maybe i'll do a patch
Sep 12 11:19:59 <loswillios> Memphiz: I build an image two days ago and flashed my dockstar successfully
Sep 12 11:20:30 <Memphiz> loswillios: i just exchanged the uboot from jeff with this builded from trunk ...
Sep 12 11:20:46 <Memphiz> and it was not page aligned and nandwrite complained that and didn't write it to flash
Sep 12 11:20:57 <Memphiz> maybe u flashed a combo of u-boot and kernel?
Sep 12 11:20:57 <xMff> nandwrite -p  :P
Sep 12 11:21:08 <Memphiz> xMff: ohh cool ... thanks :)
Sep 12 11:21:36 <Memphiz> loswillios: does the 2nd stage uboot use the same env as the original 1st stage uboot?
Sep 12 11:21:50 <xMff> no
Sep 12 11:21:52 <loswillios> yes, I flashed a combo
Sep 12 11:22:26 <Memphiz> xMff: for god sake :)
Sep 12 11:28:28 <_trine> my dockstars reboot directly into openwrt with a reboot command but do not when rebooted from a repower situation in this case they boot into the original which is not what I want
Sep 12 11:29:27 <_trine> I am booting into a usb pendrive by the way
Sep 12 11:29:52 <Memphiz> _trine: just change the boot cmd in the 1st stage bootlooader to "run bootcmd_usb" ....
Sep 12 11:30:00 <Memphiz> i think ...
Sep 12 11:30:07 <Memphiz> have to look into my env again
Sep 12 11:30:18 <Memphiz> then the 2nd stage loader and openwrt is started allways
Sep 12 11:30:54 <_trine> well there seems to be a problem in that it does not recognise the usb ports properly from a repower
Sep 12 11:31:25 <Memphiz> mhh
Sep 12 11:31:51 <Memphiz> on repower my dockstar allways stucks in the 1st bootloader and doesn't execute anything ... have to give a reset mostly ...
Sep 12 11:32:04 <Memphiz> seems to be a known issue ... i think i have read of that without a solution
Sep 12 11:33:51 <_trine> the problem with this situation is that in the event of a power failure and you are not near the dockstar it is then put out of action
Sep 12 11:34:27 <_trine> as it will not then reboot back into openwrt
Sep 12 11:36:00 <Memphiz> thats right ...
Sep 12 11:36:08 <Memphiz> don't know how to fix this
Sep 12 11:37:44 <xMff> maybe by putting the "usb reset" into the boot command?
Sep 12 11:37:56 <_trine> I have no way of knowing how reliable the reports of some others are that they do not have this problem but some say their dockstars do reboot to the OS on the pendrive but I have never been able to do this
Sep 12 11:38:00 <Memphiz> xMff: on my dockstar there where no scripts executed on boot ...
Sep 12 11:38:11 <xMff> Memphiz: no bootscripts?
Sep 12 11:38:17 <Memphiz> it just hangs at the uboot prompt
Sep 12 11:38:26 <xMff> odd
Sep 12 11:38:28 <Memphiz> after poweron
Sep 12 11:38:48 <Memphiz> but it is known ... have read that somewhere ... seems to be a prob with the original 1st stage loader on dockstars
Sep 12 11:39:18 <_trine> Memphiz, I have reflashed a new bootloader onto mtd0
Sep 12 11:39:32 <Memphiz> _trine ... ohh ... the one from jeff?
Sep 12 11:39:42 <_trine> yes
Sep 12 11:39:56 <_trine> but it still exhibits the same problem
Sep 12 11:40:02 <Memphiz> mhh then there is something really strange going on *G*
Sep 12 11:40:09 <Memphiz> die you try to increase the autoboot time?
Sep 12 11:40:17 <_trine> no
Sep 12 11:40:18 <Memphiz> for giving the usb drive more time to settle?
Sep 12 11:40:39 <Memphiz> maybe this would fix the issue in your case (since your uboot seems to run scripts ... mine doesnt...)
Sep 12 11:41:09 <_trine> I have reflash both of my dockstars this way
Sep 12 11:41:28 <Memphiz> and both behave the same?
Sep 12 11:41:33 <_trine> yes
Sep 12 11:41:41 <_trine> exactly
Sep 12 11:41:51 <xMff> the u-boot should have an usb reset command which ... well ... resets the usb and scans the bus for devices
Sep 12 11:41:56 <_trine> I have a log of what happens
Sep 12 11:42:19 <Memphiz> yeah you can just stop usb and start it again ... this would initiate a rescan of drives
Sep 12 11:42:24 <xMff> it will block until the devices where detected so it should be safe to put that at the beginning of the bootcmd
Sep 12 11:42:37 <Memphiz> what xMff said :)
Sep 12 11:45:17 <Memphiz> mhh if i read the code correct ... the uboot from trunk has env adr set to overlapping the env of jeffs uboot version a bit *sigh* ...  sad
Sep 12 11:46:26 <Memphiz> mhh or maybe it doesn't ...
Sep 12 11:49:17 <Memphiz> xMff: do you know which is specifying the uboot env adr ... is it "CONFIG_ENV_ADDR" or "TEXT_BASE" ...
Sep 12 11:49:44 <Memphiz> in jeffs patch these 2 values match
Sep 12 11:49:48 <Memphiz> in trunk they differ
Sep 12 11:49:59 <xMff> Memphiz: no idea :D
Sep 12 11:50:25 <Memphiz> mhh lars should comment his config in the wiki ... *blink*
Sep 12 11:52:02 <xMff> ping larsc
Sep 12 11:52:33 <Memphiz> tried that :D
Sep 12 11:55:36 <Memphiz> KanjiMonster: did you put openwrt on your dockstar already? maybe with the uboot from trunk as 2nd stage loader? ^^
**** BEGIN LOGGING AT Sun Sep 12 11:57:28 2010
Sep 12 11:58:38 <KanjiMonster> I fear they don't want to honor the order since they increased the price shortly after ordering :/
Sep 12 11:58:50 <Memphiz> hehe yeah ... i've heard of that ...
Sep 12 11:58:57 <Memphiz> but you should have had luck i think
Sep 12 11:59:41 <KanjiMonster> gotta go, bbl
Sep 12 12:05:05 <_trine> http://pastebin.com/7UsbLYyc  Thats a pastebin of one of my dockstars booting
Sep 12 12:07:47 <_trine> there several boots included in the pastebin which show that a 'reboot' command does reboot OK but not OK from a repower situation
Sep 12 12:08:29 <_trine> from a repower it does not find all the usb ports
Sep 12 12:12:11 <Memphiz> _trine you should try to increase the bootdelay in env at first ... for giving the drive some more time ...
Sep 12 12:12:57 <Memphiz> if that doesn't work ... you have to alter your bootcmd to do a usb_init before the "run bootcmd_usb"
Sep 12 12:13:50 <_trine> Memphiz: whats the env command for this
Sep 12 12:13:59 <_trine> setenv ?
Sep 12 12:14:03 <Memphiz> yes
Sep 12 12:14:09 <_trine> yes but what
Sep 12 12:14:23 <Memphiz> for increasing the bootdelay go into your uboot
Sep 12 12:14:34 <Memphiz> and issue "setenv bootdelay 10"
Sep 12 12:14:34 <_trine> yes but which one is it
Sep 12 12:14:36 <Memphiz> then "saveenv"
Sep 12 12:14:38 <_trine> ah
Sep 12 12:14:50 <Memphiz> this would give 10 secs before initialising the usb
Sep 12 12:15:38 <_trine> setenv is not correct
Sep 12 12:15:59 <_trine> root@debian:~# setenv bootdelay 10
Sep 12 12:15:59 <_trine> -bash: setenv: command not found
Sep 12 12:17:37 <_trine> opps
Sep 12 12:17:44 <Memphiz> lol
Sep 12 12:17:48 <_trine> I just saw it wa sin debian
Sep 12 12:18:14 <_trine> he he
Sep 12 12:21:13 <Memphiz> seems lars put the env outside of the uboot partition ... this would overwrite the original dockstar kernel if i'm right ... this wouldn't be not soo nice ... i don't think i am the only one who doesn't flash openwrt on the box, but use external storage and boot from usb ... and wanting the original firmware there for recovery and other things ...
Sep 12 12:24:03 <_trine> fw_setenv bootdelay 10
Sep 12 12:24:09 <Memphiz> _trine
Sep 12 12:24:11 <Memphiz> no
Sep 12 12:24:11 <_trine> is the correct command
Sep 12 12:24:16 <Memphiz> it is not ...
Sep 12 12:24:22 <_trine> oh
Sep 12 12:24:29 <Memphiz> as i said ... do it in the u-boot! not inside the booted linux
Sep 12 12:25:04 <Memphiz> in u-boot it should be setenv ... in booted linux it could be fw_setenv ... but only if the /etc/fw_config would be altered accordingly ...
Sep 12 12:25:11 <_trine> but can you not just alter it in this way as well
Sep 12 12:25:33 <Memphiz> depends on your config file for fw_setenv
Sep 12 12:26:13 <Memphiz> if it matches your uboot environment then yes ... but i would do it in uboot because i don't trust in the uboot-envtools (which fw_setenv belongs to)
Sep 12 12:26:36 <Memphiz> err /etc/fw_env.config
Sep 12 12:26:48 <Memphiz> so what did you do now?
Sep 12 12:26:54 <Memphiz> used fw_setenv?
Sep 12 12:27:00 <_trine> fw_setenv bootdelay 10
Sep 12 12:27:06 <_trine> I did that
Sep 12 12:27:24 <Memphiz> and did it complain about something?
Sep 12 12:27:28 <_trine> no
Sep 12 12:27:32 <_trine> it was fine
Sep 12 12:27:33 <Memphiz> issue fw_printenv
Sep 12 12:27:38 <Memphiz> do you see your altered value?
Sep 12 12:28:11 <_trine> yes
Sep 12 12:28:30 <Memphiz> whats the output of /etc/fw_env.config
Sep 12 12:29:17 <Memphiz> cat /etc/fw_env.config
Sep 12 12:29:28 <_trine> this is the output of fw_printenv
Sep 12 12:29:36 <_trine> http://dpaste.com/242282/
Sep 12 12:30:14 <Memphiz> cat /etc/fw_env.config <- please
Sep 12 12:30:32 <Memphiz> the output of fw_printenv seems to be uncomplete
Sep 12 12:30:41 <Memphiz> incomplete
Sep 12 12:30:43 <_trine> http://dpaste.com/242283/
Sep 12 12:30:59 <Memphiz> that looks ok i think
Sep 12 12:31:26 <_trine> I'll try a cold reboot now
Sep 12 12:31:29 <Memphiz> well .. then you should reboot the box ... and should see a countdown from 10 to zero on your serial
Sep 12 12:31:36 <Memphiz> you could first try a warm reboot
Sep 12 12:31:39 <Memphiz> but nevermind ;)
Sep 12 12:32:27 <_trine> no it's just the same
Sep 12 12:32:53 <Memphiz> have you serial connected?
Sep 12 12:33:23 <_trine> I can't attach the serial right I'm getting grief off my wife because she wants me to go out
Sep 12 12:33:29 <_trine> :(
Sep 12 12:33:46 <Memphiz> well ... nothing a can do about here ;)
Sep 12 12:33:50 <_trine> I'll be back later
Sep 12 12:34:08 <_trine> do we have any contract wife killers on channel
Sep 12 12:34:15 <Memphiz> i go for vacation 2 weeks ... so maybe the others should help you further then ;)
Sep 12 12:34:29 <Memphiz> lol ... i don't hope so :)
Sep 12 12:34:29 <_trine> well have a great time
Sep 12 12:34:37 <Memphiz> thx
Sep 12 12:34:43 <_trine> where are you going to
Sep 12 12:34:54 <Memphiz> baltrum ... its a little island in the northsea ...
Sep 12 12:35:13 <_trine> never heard of that place I will look it up
Sep 12 12:35:19 <_trine> see you all later
Sep 12 12:35:23 <Memphiz> ciao
Sep 12 12:35:25 <_trine> bye
Sep 12 13:16:30 <builder> build #79 of s3c24xx is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/s3c24xx/builds/79
Sep 12 14:40:15 <swalker> updated openwrt/upstream, https://home.comcast.net/~sdwalker/uscan/uscan.shtml
Sep 12 14:45:31 <[florian]> swalker: nice graphs at the end
Sep 12 14:53:50 <builder> build #78 of ps3 is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/ps3/builds/78
Sep 12 14:58:27 <swalker> [florian]: they're at least something to break up the mountain o' table rows
Sep 12 14:59:13 <[florian]> swalker: yeah
Sep 12 15:34:55 <CIA-57> mb * r23028 /trunk/package/kernel/modules/crypto.mk:
Sep 12 15:34:55 <CIA-57> Fix compilation of crypto modules.
Sep 12 15:34:55 <CIA-57> This fixes #7920
Sep 12 15:36:12 <_trine> can anyone spot why my usb pendrive does not boot from a repower situation,, on booting the dockstar seems to think the uImage is wrong with the message;; Wrong Image Format for bootm command
Sep 12 15:36:44 <_trine> this is the pastebin of printenv and a log of the boot sequence
Sep 12 15:36:55 <_trine> http://dpaste.com/242334/
Sep 12 15:38:34 <_trine> after it has booted i can issue reboot and it does then reboot into the desired OS
Sep 12 15:38:53 <_trine> but never from a cold powerup
Sep 12 17:09:23 <builder> build #99 of ep93xx is complete: Failure [failed compile_6]  Build details are at http://tksite.gotdns.org:8010/builders/ep93xx/builds/99
Sep 12 20:53:49 <CIA-57> jow * r23029 /trunk/ (4 files in 3 dirs):
Sep 12 20:53:49 <CIA-57> [buildroot] Implement an ARCH_PACKAGES variable which defaults to BOARD but can be overridden on a per-subtarget basis.
Sep 12 20:53:49 <CIA-57> This is intended for targets such as adm5120 and malta which support both big and little endianess and will replace
Sep 12 20:53:49 <CIA-57> the target specific exceptions in package-defaults and Image Builder.
Sep 12 20:54:30 <CIA-57> jow * r23030 /trunk/target/linux/malta/ (be/target.mk le/target.mk): [malta] override ARCH_PACKAGES
Sep 12 20:54:46 <CIA-57> jow * r23031 /trunk/target/linux/adm5120/ (router_be/target.mk router_le/target.mk): [adm5120] override ARCH_PACKAGES
Sep 12 21:19:58 <CIA-57> jow * r23032 /trunk/ (6 files in 3 dirs):
Sep 12 21:19:58 <CIA-57> [package] opkg:
Sep 12 21:19:58 <CIA-57> - implement --add-dest and --add-arch commandline options, this allows to run entirely without configuration
Sep 12 21:19:58 <CIA-57> - tweak default config location patch to not require a config in offline root mode
Sep 12 21:19:58 <CIA-57> - rename --force-run-hooks option to --force-postinstall, its a more appropriate name
Sep 12 21:19:58 <CIA-57> - utilize new opkg commandline options in package-ipkg.mk and remove config file generation
Sep 12 21:27:10 <CIA-57> florian * r23033 /trunk/target/linux/generic/patches-2.6.35/ (20 files): [kernel] refresh 2.6.35 patches
Sep 12 21:27:22 <CIA-57> florian * r23034 /trunk/target/linux/brcm63xx/patches-2.6.35/ (110-gpiodev.patch 300-wl_exports.patch): [brcm63xx] refresh 2.6.35 patches
Sep 12 21:27:28 <CIA-57> florian * r23035 /trunk/target/linux/brcm63xx/patches-2.6.35/ (180-udc_preliminary_support.patch 240-spi.patch): [brcm63xx] register udc and spi devices at the correct init level
Sep 12 21:27:33 <CIA-57> florian * r23036 /trunk/target/linux/brcm63xx/profiles/200-GW6X00.mk: [brcm63xx] change the Tecom GW6x00 profile to use wl instead of b43
Sep 12 21:27:40 <CIA-57> florian * r23037 /trunk/target/linux/brcm63xx/ (30 files in 2 dirs): [brcm63xx] remove 2.6.33 support
Sep 12 21:27:45 <CIA-57> florian * r23038 /trunk/target/linux/brcm63xx/Makefile: [brcm63xx] default to using 2.6.35
Sep 12 21:56:06 <builder> build #72 of x86 is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/x86/builds/72
Sep 12 22:08:04 <CIA-57> jow * r23039 /trunk/target/imagebuilder/ (4 files in 2 dirs):
Sep 12 22:08:04 <CIA-57> [imagebuilder]
Sep 12 22:08:04 <CIA-57> - sync with host opkg changes
Sep 12 22:08:04 <CIA-57> - get rid of autogenerated opkg.conf
Sep 12 22:08:05 <CIA-57> - utilize dl/ as package cache, useful for remote downloads
Sep 12 22:17:20 <CIA-57> jow * r23040 /branches/backfire/ (12 files in 7 dirs): [backfire] merge r23029, r23030, r23031 and r23032
Sep 12 22:18:08 <CIA-57> jow * r23041 /branches/backfire/target/imagebuilder/ (4 files in 2 dirs): [backfire] merge r23039
Sep 12 22:23:25 <CIA-57> jow * r23042 /trunk/rules.mk: [buildroot] drop the usr/ prefix when scanning for libgcc.a
Sep 12 23:43:00 <builder> build #75 of uml is complete: Failure [failed compile_7]  Build details are at http://tksite.gotdns.org:8010/builders/uml/builds/75
Sep 13 00:18:14 <builder> build #78 of ar7 is complete: Success [build successful]  Build details are at http://tksite.gotdns.org:8010/builders/ar7/builds/78
Sep 13 01:21:29 <RealOpty> xMff, you around?
Sep 13 01:21:49 <xMff> yes
Sep 13 01:22:47 <RealOpty> i have a patch that i was gonna release months ago. should i upload it to a ticket?
Sep 13 01:22:54 <xMff> yes
Sep 13 01:28:00 <RealOpty> xMff, https://dev.openwrt.org/ticket/7928
Sep 13 01:28:42 <xMff> useless is not such a great name
Sep 13 01:28:57 <xMff> can't you just remove it completelyß
Sep 13 01:28:58 <xMff> ?
Sep 13 01:29:23 <xMff> if its hardwired anyway there's not much interest in exposing it to the system
Sep 13 01:29:28 <RealOpty> can do that too. it dont make any sense having it there
Sep 13 01:29:59 <xMff> or at least comment it out
Sep 13 01:32:29 <RealOpty> RealOpty, ive uploaded a removed version to the ticket.
Sep 13 01:36:59 <xMff> k
Sep 13 01:39:35 <CIA-57> jow * r23043 /trunk/package/broadcom-diag/ (Makefile src/diag.c): [package] broadcom-diag: SimpleShare: expose power button as reset to the system, remove actual reset button - it's hardwired and will reset the SoC (#7928)
Sep 13 01:40:36 <RealOpty> ty.
Sep 13 01:41:19 <xMff> is the simpleshare supportedi n backfire?
Sep 13 01:41:45 <RealOpty> yes. i was thinking about backfire too
Sep 13 01:42:03 <RealOpty> i thought failsafe was broken in backfire?
Sep 13 01:42:40 <CIA-57> jow * r23044 /branches/backfire/package/broadcom-diag/ (Makefile src/diag.c): [backfire] merge r23043
Sep 13 01:42:47 <xMff> broken?
Sep 13 01:43:42 <RealOpty> idk never tested it
Sep 13 01:43:47 <xMff> k
Sep 13 01:44:05 <RealOpty> i think someone told me that it didnt work in backfire
Sep 13 01:44:30 <RealOpty> but thanks for fixing it in backfire too :)
Sep 13 01:47:27 <RealOpty> xMff, remember this hack -> bcm47xx_parts[3].offset = size - ROUNDUP(NVRAM_SPACE, mtd->erasesize) * 2;
Sep 13 01:47:39 <xMff> yes
Sep 13 01:47:55 <RealOpty> that sorta fixed the nvram on this device, i can get changes saved between reboots now
Sep 13 01:48:22 <RealOpty> the CFE still reports a 'restoring NVRAM' ?
Sep 13 01:48:36 <RealOpty> maybe some checksum is being overwritten?
Sep 13 01:48:42 <xMff> maybe
Sep 13 01:48:57 <xMff> it will probably compare the crc8 values of both copies
Sep 13 01:50:03 <RealOpty> to make sure the 'backup nvram' is a clone of the nvram?
Sep 13 01:50:17 <xMff> yes
Sep 13 01:50:42 <xMff> you should dump the mtd partition after a nvram set commit
Sep 13 01:50:46 <xMff> and after a reboot
Sep 13 01:50:55 <xMff> then compare them with vbindiff or a similar tool
Sep 13 01:51:22 <xMff> the nvram tool will use the first one
Sep 13 01:51:57 <RealOpty> kk, how do i make a dump of the partition? i dont remember the commands for dd or w/e
Sep 13 01:52:11 <xMff> cat /proc/mtd
Sep 13 01:52:21 <xMff> is the erase size 10000 or 20000 ?
Sep 13 01:53:21 <RealOpty> idk, let me power it up
Sep 13 01:54:59 <builder> build #113 of ar71xx is complete: Failure [failed compile_7]  Build details are at http://tksite.gotdns.org:8010/builders/ar71xx/builds/113
Sep 13 01:55:34 <RealOpty> xMff, how do i find out what erase size?
Sep 13 01:55:41 <xMff> cat /proc/mtd
Sep 13 01:56:11 <RealOpty> ah
Sep 13 01:56:22 <RealOpty> xMff, the erase is only 10000
Sep 13 01:56:32 <RealOpty> but the size is 20000
Sep 13 01:57:15 <xMff> dd if=/dev/mtdblockX of=/tmp/dump bs=65536 count=2
Sep 13 01:57:24 <xMff> X being the number of the nvram partition
Sep 13 01:57:32 <RealOpty> indeed
Sep 13 01:59:37 <xMff> it should be mostly FF bytes when viewd in a hex editor
Sep 13 01:59:44 <xMff> and two blocks starting with FLSH
Sep 13 02:05:04 <RealOpty> ok so
Sep 13 02:05:26 <RealOpty> I see the second nvram that has a FLSH block header
Sep 13 02:05:37 <RealOpty> but the 1st one dont have it.
Sep 13 02:05:46 <xMff> interesting
Sep 13 02:05:51 <xMff> run "nvram info"
Sep 13 02:05:55 <xMff> which offset does it report?
Sep 13 02:06:31 <RealOpty> Offset:        0x00008000
Sep 13 02:06:43 <xMff> the partition is 0x20000
Sep 13 02:06:59 <xMff> at which offset is the first one?
Sep 13 02:08:45 <RealOpty> idk what i need to do ;p
Sep 13 02:09:09 <xMff> oh well, just upload the dumps somewhere
Sep 13 02:09:14 <RealOpty> are you asking about the offset of the FLSH in the file?
Sep 13 02:09:26 <RealOpty> ok ill upload
Sep 13 02:12:25 <RealOpty> xMff, pm me email
Sep 13 02:12:37 <xMff> xm@subsignal.org
Sep 13 02:16:50 <RealOpty> xMff, so power on do set commit, then dump, then reboot then dump?
Sep 13 02:17:03 <xMff> yes
Sep 13 02:20:44 <RealOpty> xMff, k sent two emails
Sep 13 02:21:13 <RealOpty> first was a dump after bootup
Sep 13 02:21:25 <RealOpty> then there is after commit and after reboot
Sep 13 02:24:43 <xMff> second nvram is at 18000
Sep 13 02:24:47 <xMff> as suspected
Sep 13 02:27:08 <xMff> primary is at 08000
Sep 13 02:27:19 <xMff> the one at 18000 is updated by the bootloader
Sep 13 02:28:07 <xMff> so everything looks like its supposed to look
Sep 13 02:32:35 <RealOpty> ah ok.
Sep 13 02:32:59 <RealOpty> so the cfe is just merging the changes to the backup
Sep 13 02:33:04 <xMff> yes
Sep 13 02:39:48 <RealOpty> ok cool so the '* 2' hack fixes the nvram problems on this device :) ty.
Sep 13 02:40:24 <xMff> np
Sep 13 02:40:40 <xMff> I suppose the hack is not in the repo yet?
Sep 13 02:41:51 <RealOpty> nope its not. i wouldnt know how to go about making it work and not affect other hardware.
Sep 13 02:42:06 <xMff> board detect based on nvram
Sep 13 02:42:12 <xMff> it has some nice SimpleShare string
Sep 13 02:42:39 <RealOpty> ah yeah duh Hauke just added all that nvram stuff to the flash map
Sep 13 02:42:42 <xMff> model_name=SimpleShare
Sep 13 02:43:36 <xMff> char *model = nvram_get("model_name"); if (model && !strcmp(model, "SimpleShare") { do flashmap fix }
Sep 13 02:43:43 <xMff> something in this spirit
Sep 13 02:44:54 <xMff> other useful var is pmon_ver and the fact that there's a second nvram
Sep 13 02:45:12 <xMff> should be enough to reliably detect this model
Sep 13 02:45:51 <RealOpty> yeah. there is a few detections listed in the broadcom-diag/diag.c
Sep 13 02:46:01 <xMff> not diag though
Sep 13 02:46:04 <xMff> must happen earlier
Sep 13 02:46:14 <xMff> when the flashmap is constructed
Sep 13 02:46:14 <RealOpty> i think its the board number it uses to detect
Sep 13 02:46:20 <xMff> that is ages before diag gets loaded
Sep 13 02:47:09 <RealOpty> or at least the first few numbers of the board num is used to detect
Sep 13 02:47:23 <RealOpty> cause the boardnumbers vary
Sep 13 02:47:37 <RealOpty> i think they all start with something like 04 or w/e lo
Sep 13 02:47:38 <xMff> checking...
Sep 13 02:48:03 <RealOpty> yeah 04F
Sep 13 02:48:26 <RealOpty> my board num is 04FN54702513_SD_C-06
Sep 13 02:49:43 <RealOpty> if (startswith(boardnum, "04FN")) /* SimpleTech SimpleShare */
Sep 13 02:50:04 <RealOpty> if (startswith(getvar("pmon_ver"), "CFE")) {
Sep 13 02:50:15 <RealOpty> those are the checks that diag.c uses
Sep 13 02:51:22 <xMff> he only excludes the board data though
Sep 13 02:51:28 <xMff> the duplicate nvram is not handled
Sep 13 02:52:37 <RealOpty> i know its not patched in target/linux/brcm47xx/files-2.6.34/drivers/mtd/maps/bcm47xx-flash.c
Sep 13 02:52:54 <RealOpty> i was just pointing out ways to identify the device
Sep 13 02:57:59 <RealOpty> xMff, on my netgear i see this message printed from CFE. Checksum mismatch
Sep 13 02:58:10 <RealOpty> Image chksum: 0xFFFFFFFF
Sep 13 02:58:10 <RealOpty> Calc  chksum: 0x00000000
Sep 13 02:58:30 <xMff> hmm
Sep 13 02:58:59 <xMff> in this context F...F and 0...0 are probably the same
Sep 13 02:59:14 <xMff> I mean logic wise
Sep 13 02:59:23 <xMff> looks like loader wants it as 0 and not F
Sep 13 02:59:24 <RealOpty> i think it has something to do with .chk files that are used to flash the router.
**** ENDING LOGGING AT Mon Sep 13 02:59:57 2010