I'm trying to do a custom build for my wndr3700v2 APs (from trunk) , but the builds that I am making do not appear to be working, but the snapshot images are working for me.

I'm assuming that it's something that I am doing wrong in my .config (no compile errors, just that the result is not pingable after being flashed). Is the .config used to compile a firmware image included anywhere in it so that i can grab a known-good config and try to compile it?

You can find the build .config in the corresponding download folders.

I may be looking in the wrong place, but looking in http://downloads.openwrt.org/snapshots/trunk/ar71xx/ I am not seeing anything that looks like a config file. what am I missing.

I guess it's only relevant for the stable backfire release:

http://backfire.openwrt.org/10.03.1/ar71xx/

Config file is built automatically for you with 'make menuconfig', where you make selections. So it is not anywhere in the sources. (Pieces of are scattered around, as it is parsed from default & device-specific scripts after you select your device).

If you want a working wndr3700 .config as a template, you might grab my or Arokh's config from the Community release section of the forum.

The .config from my last well-working stable trunk build: http://koti.welho.com/hnyman1/Openwrt/t … 853.config
Backfire config: http://koti.welho.com/hnyman1/Openwrt/b … 003.config

(Last edited by hnyman on 12 Jan 2012, 10:09)

I knew that .config is created by make *config, my question was if the resulting .config file gets stored in the resulting firmware .img or .bin file.

the idea is that if you find a build that does almost what you want, you don't have to try to recreate it from scratch, you can grab the file from the image (or from the router with the image installed), put in in your build tree and do make oldconfig to get it up to date and go from there. (or if you loose the config file you used to create a firmware image, but still have a router running it :-)

I think I've found one at this point, but I think it would be a good option (and pretty cheap space wise) to have it included in the final firmware if it's not already an option.

the kernel has the option to include the config in the resulting kernel (it's available as /proc/config.gz with the option set) and is very useful to have.

The .config file is rather large and will take some precious bytes in the image, so that will most likely not be part of the default build. (Wndr3700v2 has so large flash that it is not a problem.)

However, you can easily add a step to your build script to 'cp .config files/etc/.config' between 'make menuconfig' and final 'make world'. Then the file will get included in your image as /etc/.config.  (The files stored in <buildroot>/files do get included in the image.)

EDIT:
Another smaller alternative would be to create a seed .config file, which can be blown to full .config with 'make defconfig'. I have a 40-lines .config.init, which I copy as .config, run 'make defconfig' and get the full .config out of it. (All other config lines are created from defaults by defconfig.) Including that .config.init in build would only take a few kilobytes.

See https://forum.openwrt.org/viewtopic.php … 78#p147078

(Last edited by hnyman on 12 Jan 2012, 18:56)

It's not that large, 20kb gzipped. I include them in my builds.

I'm not saying it should be default on all builds (if you are tight on space you trim everything), but having it as a standard option would let it be part of the defaults on the larger routers. At 20K gzipped and 120K native it's not _that_ large, if you are running luci on a system you probably have that much to spare.

Snapshot builds are simple:

./scripts/feeds update
./scripts/feeds install -a

cat <<EOT > .config
CONFIG_TARGET_foo=y
CONFIG_ALL=y
# CONFIG_PACKAGE_ebtables is not set
EOT

make defconfig
make V=99 IGNORE_ERRORS=m

No magic involved. Though the .configs generated in such a way are mostly useless, nobody really wants to build everything.

Also I think that embedding full .config files is a waste of space, several dozens of kilobytes just to list what is not enabled.
If at all you should embed the scripts/diffconfig.sh output and let make defconfig inflate it on a build, that also helps to avoid
issues like the shadow password debacle.

Finally there is no gurantee that .configs remain compatible - if you'd try to compile current trunk with a .config from a few
months ago it'll most likely just fail.