OpenWrt Forum Archive

Topic: .config for official released images?

The content of this topic has been archived on 19 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi,

I'd like to build my own image with some tweaks, but first, I want to start with some known-good configuration, if possible the same one as used for official released images. Are these config files (at least for Asus WL500GD, "bin" subtype) available somewhere? I hope I'm not overlooking something obvious 8)

thanks.

DEVELOPER=1 make menuconfig; make

Thanks for answer, but I'm not sure I expressed myself clearly: DEVELOPER=1 apparently enables extra settings in the menuconfig. Instead, I'd like to see .config files used in official RC5 brcm bin and micro images, so I could check out what packages and kernel options they use and then tune them for my own image.

The DEVELOPER=1 enables all packages and then imagebuilder is used to assemble the packages into the various firmware images.

mbm wrote:

The DEVELOPER=1 enables all packages and then imagebuilder is used to assemble the packages into the various firmware images.

Yes, I know. What I want to know is exactly what packages and what kernel options are used in each of the released firmware images. I assume that developer in charge of releases has some .config-bin, .config-pptp and .config-micro files, which he uses to build each flavour. Is that correct? I'd like to see these files...

You still don't understand it and you seem unwilling to actually look into it, so let me spell it out for you in detail -

If you take a fresh checkout of the sources, nothing built and no config files and then run "make menuconfig DEVELOPER=1" you'll get a menuconfig screen with nearly every single package enabled. Exit and save this configuration, this will produce a .config file -- this config file specifies how and what to compile, this is the only config file ever used. Running "make" will then compile all the packages and produce a bin/packages directory; this directory is then uploaded as the ipkg repository, ex: http://downloads.openwrt.org/whiterussian/rc5/packages/

This will also produce a few other items, a firmware image (completely ignored), an SDK (contains the compiler and some basic framework; uploaded) and something called ImageBuilder. At no point will we ever go back and change our .config file or recompile anything; the packages are already built and it's simply a matter of transforming those packages into a firmware image -- this is what ImageBuilder does.

ImageBuilder is completely incapable of building/compiling/modifying any packages or kernel options, it's basically an overgrown version of ipkg. There is absolutely zero configuration required to use ImageBuilder; the list of which packages get added to which firmwares is built into ImageBuilder itself (look under the lists/ directory). The job of ImageBuilder is to simply to extract a set of packages a set of packages into a temporary directory representing /, convert that directory into a filesystem image, then to take that filesystem, add a kernel and produce a trx file. It does this for each filesystem (squashfs, jffs-4M, jffs-8M) in each list (default, micro, pptp). Headers are then added to the trx files to produce bin files, a "openwrt-brcm-2.4-squashfs.trx" becomes several different "openwrt-<model>-squashfs.bin" files. When all the default/micro/pptp directories are filled with a confusing number of trx and bin files, the entire mess is then uploaded to the openwrt.org servers.

A 00-README is "written" using an excessive amount of cutting and pasting from the previous 00-README and the wiki, and a release announcement is made.

---

Note: This is completely excessive for building just a single image for personal use; the defaults in "make menuconfig" will work perfectly fine.

Thank you, that's the answer I was looking for.

I'm sorry that you feel any unwillingnes on my part. I just misunderstood your build process, thats all.

Again, thanks for an in-depth and helpful answer.

The discussion might have continued from here.