hey guys,

there are a couple of things I do not understand when working with
buildroot:
- whats the difference between BR2_EXT_UCLIBC_VERSION_0_9_28_3=y
and BR2_USE_UCLIBC_SNAPSHOT="20080926" in the config file? any doc to see
what those defines mean?
- there are 3 filesystems that can be selected. some config files select
all of them but actually it should be ok to just select the jffs2, right?
what about the others?
-I got the latest buildroot snapshot which contains a defconfig for my
board with at least 25 lines. buildroot from 2010 contains a complete
defconfig with hundreds of lines. what happened here?

Hi there

For an older SoC such as the 926x, there is not much benefit for using/testing the latest versions of anything, unless there is a specific fix or feature that you require. The drivers (except maybe I2C) for 926x stabilized since kernel version 2.6.27 in 2008. For a first effort, you are better off using *stable* versions rather than a (daily) snapshot. Stable or released versions should have code changes with the best ratio of fixes versus new-or-unknown bugs.

> - whats the difference between BR2_EXT_UCLIBC_VERSION_0_9_28_3=y
and BR2_USE_UCLIBC_SNAPSHOT="20080926"

If you could find the release date for uClibc version 0.9.28.3 (2007 ?), then you'd know if it was newer or older than the snapshot dated 26 Sept 2008. If you're going to use a snapshot, a version from this decade would be more suitable. It's probably stale/unmaintained code you're looking at. You are supposed to manually enter/edit an appropriate date (a year|month|day within the quoted string) for the snapshot of your choice.

uClibc was recently (Oct 2011) patched to fix a Daylight Savings bug. That should be a good reason to use the recent release 0.9.32.1 or a snapshot if you use the RTC/RTT and calender/clock functions.

> - there are 3 filesystems that can be selected.

Choose what suits your needs and how big your kernel can be. In the end I trim out *all* unnecessary kernel options by going through every path in menuconfig. Treat the defconfig file as just suggestions or a starting point.

Regards

thank you for the reply!

Another question:
First thing I did was to invoke "make at91sam9263ek". this step copies my config file in the root dir.
next step was to invoke "make menuconfig" to setup individual settings. Linux Kernel was not selected so I did it on my own: 2.6.36. Unfortunately the patch delivered by buildroot is only for 2.28. can I use this one or should I use this one: "http://maxim.org.za/AT91RM9200/2.6/2.6.36-at91.patch.gz" (for me it would be nice to use the 2.6.28 patch because options are already set correctly for my board!)?
next step would be - via "make menuconfig" - set "use custom kernel patch" and provide the path to the patch.
would you agree on this procedure?

.config defines for Kernel build:

Hi there

I have to confess that I haven't used the latest version of Buildroot, and it has been a while since I've used the top-level menuconfig. If you haven't done so already, the primary goal in first using Buildroot is building the GCC crosscompiler and other build tools. This phase of Buildroot takes the longest, but once done, you can then build any kernel configuration you want rather quickly.

> First thing I did was to invoke "make at91sam9263ek".
So this establishes the "board" and arch and processor for this instance of Buildroot. Go ahead and try a configuration that appears suitable. Worse case is that you abandon this build, rename or zap the top directory, and start over. Hint: locate all of the downloaded archives outside the Buildroot directory so that start over is painless and fast.

> it would be nice to use the 2.6.28 patch because options are already set correctly for my board!
That may have been one of the last kernel versions tested for 926x EK boards. I vaguely recall reading that there are too many ARM boards to test compile, so the maintainers may have dropped test compiles for older boards such as 926xEKs.

As I previously wrote, you need to determine what you need in the kernel. If 2.6.28 has enough to support application testing for now, then that version is going to be the quickest path in getting some demo code running. It can be very demoralizing while spending days trying to bringup a new kernel. And it's not like that once you build an older version that you are stuck using that version forever. At this point your goal is probably to get any custom kernel running, and not the final version that's going to be released with product.

Match the proper patch file to the kernel version! Maxim.org.za is the semi-official site to get the Atmel patches.

Regards

well, I finally made it and just want to report back my status:
I built the toolchain with buildroot. I used the 2010 revision because there was a 9263ek_defconfig available. no idea why this one is not in the latest release. I deselected everything that was not necessary like linux and the filesystem. The result was a nice working toolchain. I could built uboot with no problem.

thank you for the support!

btw, the main reason it didnt work before was the fact that the embedded linux that was deployed was built with open embedded and one doesnt know which headers and libs were used. It's always better to build everything from scratch to know whats going on!