U-Boot environment in dataflash not saving and showing CRC errors
 

We are working with an Atmel SoC (AT91SAM9G20) and we have both NAND and DataFlash (NOR connected with SPI). The DataFlash is the boot device, bootstrap->U-Boot->Linux... with a twist: bootstrap and U-Boot in DataFlash and Kernel and RootFS in NAND. Before I moved the kernel to NAND U-Boot was fine with its environment. But after I got through redefining the boundaries for items in DataFlash, U-Boot could no longer find its environment variables. "saveenv" does not seem to actually save the information to DataFlash either.

I am having trouble using U-Boot commands to read the contents of the DataFlash so I can verify that the ubootEnv is getting written there. Any ideas on that?

I guess I got lucky. I found that in partitions.c for my platform, I put the wrong chip select value for the DataFlash we have... and so U-Boot could not probe it and subsequently could not access. That explains each of the issues.

This problem is now solved.

Well, my project was similar. I used the AT91SAM9G45 processor with Bootstrap, U-Boot Environment Variables, U-Boot, and a BMP Splash screen all in a SPI flash (similar to dataflash). My Kernel is at offset 0x00000000 in NAND with RFS 4 MBytes into NAND.

I has several problems that may or may not effect you.

1) My custom hardware was unable to reliably run U-Boot in DDR at 133 MHz using my Hynix Mobile DDR but did work fine using my Micron Mobile DDR. Run memtest from U-Boot. (My HW is not in front of me for the exact command). I will try and post more on Monday when I get back to my desk. I still have to run my DDR bus at 100 MHz on my Hynix DDR boards so that U-Boot and Linux are stable. The odd thing is my routing is very tight and conservative. No crazy vias, decent trace widths, IC's within 500 mil, Differential clock bus routed first, da da da.

2) My co-engineer (DSP guy) wanted his FPGA to boot over the same SPI at 66 MHz. Even though Atmel does allow crazy SPI speeds, there are notes about I/O capacitance and loading that prevent the I/O pin from wiggling much faster then 30 MHz. I settled on 20 MHz and all is well.

3) I didn't like the U-Boot SPI routines so I moved all of my board init down into my bootstrap code and then recoded the SPI Transfer routines.

4) I didn't like SAMBA so I re-wrote a primitive SAM-BA MFC Windows application that talks out the serial port to my bootstrap so I can upload and download SPI Flash memory so that I could test and see what was really being written and read. That and some U-Boot debug statements to help me muddle through.

P.S. I am pretty new to all of this and just learning over the past 4 months.

Sorry Johnbond, finally saw your reply to yourself. Oh well, my text might help someone else. Glad you fixed your problem.

GSinde, thanks for your reply, actually.

It is good to know that others are using these parts and are struggling with Linux/U-Boot on the Atmel ARM SoCs. I am very excited about this task as well. There are many aspects of Linux for which I am a newbie, but several where my experience with UNIX in the 80's and 90's is helpful. I don't like the fact that many things don't work out of the box (like SAM-BA), but I will not complain because this stuff is exactly what I would be doing if I had time for it as a hobby.

My only real problem is that the software team should have completed this already. So this puts my boss in the hot-seat. Back to work.

I am also very interested in your SAM-BA replacement...

John Bond

Hi John,

I basically created my SAM-BA (I called it TriSamBa) to do the following:
1) Download my bootstrap to a cold dead board and run it via DEBUG COM PORT
2) upload and download serial flash via DEBUG COM PORT

The key piece of the puzzle was the SAM-BA commands via the Serial Port
(There is a document on the Atmel site that explains all except the HELLO ROM CODE command which is KEY)
HELLO ROM CODE (must be done first) -> 0x80, 0x80, '#'
GOTO TEXT MODE (usually done second) -> 'T', '#'
DOWNLOAD (usually 1 byte at a time) -> sprintf((char *)&command, "O%8.8X,%2.2X#", (address + numbytes), (unsigned char)tmp[0]);
GO (execute downloaded code at address) -> sprintf((char *)&command, "G%8.8X#", address);

Once, my Bootstrap is running, you can code anything you want in there and get as elaborate as you want over the serial port. I added full LCD, keypad, DDR, serial flash, etc. testing for my production folks. My Bootstrap is now around 30KBytes and contains all kinds of test code for my custom hardware.

Gary

P.S. I used a company called Timesys to jump start me because I knew ZERO Linux when I began Q4 2010. They provided a quick up and running toolchain and build system for under $5K. This saved me countless weeks screwing around with the basic Linux config. I then just use Code::Blocks as an IDE and Qt Creator for my GUI and Webkit. Of course, I have just begun console application development and GUI development but things are working.