On Sun, 2010-07-04 at 13:25 -0700, Charles Krinke wrote:
Dear Sirs:
I have inherited a project using ltib and have studied and understood some of it, but there are some holes in my knowledge. I wonder if someone could help me out with a few clues by answering these questions.
1. When ltib starts up, what files does it use? Just .ltibrc or others?
That and others. First, ltibe looks into .ltibrc to find information about where bits are, how to access stuff, etc.
Then it looks in .config to find the platform directory to use, then in that platform direcotry (config/plaforms/<platform>), it looks for .config then defconfig.dev, then defconfig to find the configuration that describes which packages to build (and which configuration bits for those packages).
2. I find that each time I run ltib, I need to run "ltib -c" and reselect all my target parameters. Where does ltib store (and read) its configuration file from when one runs "ltib" or "ltib -c".
You shouldn't have to run "./ltib -c" - "./ltib" should build what you need unless you need to change a configuration item. ltib update config/plaform/<platform>/.config and config/platform/<platform>/defconfig.dev with any configuration changes. Are you trying to do a configuration change outside of ltib? If so then it may not get picked up until you do "./ltib -c".
3. I am having trouble consistently building uImage and rootfs.jffs2. Can someone help me understand a recipe to consistently build both? Although I can run "ltib -m shell", I get stuck on it wanting a single package. Is there a way to just build a uImage and a rootfs.jffs2 from the "ltib -m shell" ??
You can't build a full image from "./ltib -m shell" - that's only used if you need to do something outside the ordinary (i.e. just build a kernel by "cd rpm/BUILD/<linux-build-directory> && make ARCH=arm 'HOSTCC=ccache /usr/bin/gcc -B/usr/bin//' uImage && scp arch/arm/boot/uImage <user>@<target-IP>/tftpboot/" for an arm kernel that you can then load on your target with u-boot, but until you've worked with LTIB long enough, using "./ltib -m shell" can be haxardous to your work".
If your project is properly set up(and configured), then "./ltib" should just build what you want, leaving the rootfs/directory with components you can copy over to either burn or load on the target and run with....
What specifically are you doing that requires continually doing "./ltib -c" and reselecting all the components you need?
Charles
_______________________________________________
LTIB home page: http://ltib.org
Ltib mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/ltib