Buildroot of at91sam9g20ek and flashing with SAM-BA bad CRC

[nas]

Hello, I'm using a at91sam9g20ek board and I've managed to flash with SAM-BA the demo provided at linux4sam getting started page (buildroot-at91sam9g20ek-4.2.zip).
I did this using SAM-BA v2.12, on an Ubunutu 12.04 PC.
However we need to be able to deploy a custom package in buildroot on top of this, for that we'd like to be able to build the whole lot from scratch.
Following the buildroot guide on linux4sam I built the default at91sam9g20dfc_config image, with the following modifications, gcc set to snapshot (4.8.2x), file system set to UBIFS, embedded into a UBI.
I modified the SAM-BA tcl script to point to the output images, and flashed them to the board.
Here is where the problem arises, u-boot complains that the environment has a bad CRC and goes to default and does not load the Kernel or the Rootfs. As far as I can tell the uboot environement is generated dynamically on both occassions, any ideas on what's going wrong?

EDIT
-----
I've found the source in the TCL script being a hardcoded bootz, switched to bootm, as the default buildroot image is a uImage.
Now I've got a kernel panic when trying to load the rootfs, will try switching the Kernel over to zImage first to get as near as possible to the demo aside from version mis-matches, before I investigate the kernel panic.

[blue_z]

u-boot complains that the environment has a bad CRC and goes to default and does not load the Kernel or the Rootfs.

The "bad CRC" is probably a consequence of erasing the NAND partition that contains U-Boot's environment variables. As a fallback, U-Boot will use a set of predefined (aka default) environment variables.

If U-Boot does not load the kernel, it is not a direct consequence of the "bad CRC". (BTW U-Boot would not load a UBI/UBIFS rootfs; the only loadable rootfs would be a ramfs.)
Not loading the kernel could imply that there are no bootcmd and/or bootargs env variables (or their definitions aren't correctly) defined in the default environment.
But a failure description of "does not load ..." is too vague to analyze; you only mention one thing (out of many) that did not happen and you haven't described what did happen.

Do a `printenv` and review the default values. Correct them in the board's config file (to something that would boot the board).

As far as I can tell the uboot environement is generated dynamically on both occassions,

No, these env variables are not "generated dynamically" on any occasion.
On a normal boot, the environment variables are retrieved from a non-volatile storage (the device & location defined when U-Boot is built).
When that storage area does not contain a valid set of saved variables (as verified by a CRC32 check), U-Boot uses a set of variables as defined when U-Boot is configured & built.

I've found the source in the TCL script being a hardcoded bootz, switched to bootm, as the default buildroot image is a uImage.

U-Boot is expecting a uImage file, not a zImage file.

gcc set to snapshot (4.8.2x)

Why??!!
There have been GCC releases that generated bad ARM code, and you choose to use an unproven snapshot?
What do you expect to gain by using the latest version for an old 926EJ-S processor? (I.E. most ARM compiler development is for Cortex.)

Regards

[nas]

Thanks for the help bluez, just to clarify:

As far as I can tell the uboot environement is generated dynamically on both occassions,

No, these env variables are not "generated dynamically" on any occasion.

Here I was referring to the generating of the ubootenv file by the TCL script run by SAM-BA as part of the flashing process, not boot events. The two occassions being the flashing of the demo, and the flashing of the at91sam9g20dfc default from buildroot.

gcc set to snapshot (4.8.2x)

Why??!!
There have been GCC releases that generated bad ARM code, and you choose to use an unproven snapshot?
What do you expect to gain by using the latest version for an old 926EJ-S processor? (I.E. most ARM compiler development is for Cortex.)

Regards

The ultimate aim of this experiment is to evaluate the OpenDNP3 library. I hope to have one EK board running a master, another an outstation and get them communicating over ethernet. Our existing product uses the 9G20 and there are a lot of units installed on site, we do plan on moving to Cortex but our clients hardware upgrade cycle is a long one.
OpenDNP3 extensively uses C++11, I might just use the gcc 4.7 option on buildroot and see if it compiles. On x86_64 OpenDNP3 v2 candidate will not build with gcc 4.6 (gcc would segfault), the 4.8.2 tagged release was the only version which built OpenDNP3 and other dependent libraries on that platform.

[nas]

Ok, I've solved it, although the buildroot repo is Atmels own from github the u-boot default versions do not point to Atmels u-boot repo but to u-boots home itself.
By setting u-boot to custom git, setting that to Atmels u-boot repo, and setting the version to 5e9f9da8709cf8837d48e4233e44bcbd9a965045 I was able to get the Linux4sam 4.2 source and that built fine without a CRC failure.
The CRC failure was caused by missing Atmel patches where a delay is required by arm926ejs chips before the CRC calculation can be made, see the reply by Zhiqian Wang in here http://e2e.ti.com/support/embedded/linu ... 73788.aspx.