Problem initializing 9G20 with SAM-BA

When we originally received our 9G20s, they didn't have uBoot loaded. We used the instructions here to initialize it:

http://armbedded.eu/node/8

This worked until we used flash_erase on one of the mtd partitions. Then, we got a bunch of errors at boot saying "ecc unrecoverable error," followed by a countdown to prevent autoboot, and then another stream of "ecc unrecoverable error" messages.

We tried using SAM-BA to reload uBoot and the kernel into flash, but connecting pins 1 and 37 didn't change the boot behavior - it booted into Linux instead of ROM Boot, and SAM-BA reported a communication error.

By interrupting the boot, I used uBoot to do a nand erase.part on mtd7, the parition we ran flash_erase on. This didn't change anything, so I did a nand erase all.

This got rid of the ecc unrecoverable errors, and let me get into ROM Boot mode. However, when I try to connect via SAM-BA, the process connects to the COM port, but the GUI never appears after I select the board from the initial display even though the process is still running. I can tell that something is working, because if I let the board boot without shorting pins 1 and 37, SAM-BA reports a communication error.

Any ideas on how to fix this?

Re: Problem initializing 9G20 with SAM-BA

The next question is whether the flash_erase caused this, or if it could have been something else. Searching on the ecc error, it seems the error is most commonly caused by running flash_erase with a kernel that only supports 1-bit ECC flash.

The flash_erase doesn't have any problems on our older 9G20s - did the 9G20 change from 1-bit to 4-bit ECC on the flash? Even if so, why would running flash_erase on mtd7 affect the kernel on mtd2?

Re: Problem initializing 9G20 with SAM-BA

I'm not sure how old the "older boards" are, but there was a change that would affect you (see http://download.armbedded.eu/software/Stamp9G20_PortuxG20-BCH-upgrade.ta...).

The changes were:
1.) Switch to 4bit BCH-ECC as required by the new NAND modules (NQ279, NW193)
2.) Mounted DataFlash to hold the 1st-stage loader (at91bootstrap)

The boot procedure changed - code is first loaded from DataFlash address 0x0000; U-Boot is then loaded from its known location in NAND 0x20000 using 4bit BCH; Linux is loaded afterwards (0xA0000, 4bit BCH).

So to get access via SAM-BA, you have to disable the DataFlash during power up:
"Close J4 before power up, remove after connect to SAM-BA; if plugged onto the EVB, use PIN1 and PIN37 of the bus interface instead"

If you located boot code in both media (NAND and DataFlash) you also need to disable the NAND:
"Close J3 before power up, remove after connect to SAM-BA; if plugged onto the EVB, use PIN1 and PIN38 of the bus interface instead"

Please use our latest SAM-BA scripts for 4bit BCH (link is on the bottom of http://www.armbedded.eu/node/8).

Re: Problem initializing 9G20 with SAM-BA

I have a few more data points. We have two boards with the ECC error. I tried the second one today, and shorting pins 1 and 37 didn't change anything. Shorting 1 and 38 displays an error that the NAND can't be found, but shorting both displays the "RomBOOT" prompt. It's possible that the two boards were loaded differently, so I may have loaded U-Boot into DataFlash and the other person loaded it into NAND.

Regardless, when we try connecting via SAM-BA, the process continues running without bringing up the GUI we were able to get before. Is there some kind of debugging we can do to see what's happening? It doesn't time out or get a communication error like it does when we don't get the RomBOOT prompt.

Re: Problem initializing 9G20 with SAM-BA (RESOLVED)

We've got it working now. Here's the list of things that were wrong:

- We hadn't applied the patch to the kernel we were using with our 5-year-old boards - this resulted in flash_erase corrupting the flash
- We weren't shorting both PIN1/37 and PIN1/38, which we needed to do after loading the U-Boot/kernel images the first time
- We didn't realize that shorting the pins caused a USB serial port to show up in Windows. We were using the serial console output to connect SAM-BA
- We were trying to use another machine that wasn't connected to the Internet, so when the USB serial port appeared, Windows couldn't find the appropriate driver
- We hadn't noticed the additional instructions in the README file included with the U-Boot/kernel images, so we were missing a few steps

These are all resolved now, and we were able to load a new image. Thank you for your help!

Syndicate content