On 30 Dec 2008 at 11:52, Wolfgang Denk wrote:

Assuming both boards have the same configuration (or, more precisely, at least the same size of environment and environment sectors),

Yes, they are the same.

then you can just read the sector(s) containing the environment from their corresponding /dev/mtd* devices in Linux and copy it to the other system.

So you're proposing to use Linux to copy U-Boot environment. But on a new board (picked from the shelf) I don't have Linux and I should set some U-Boot variables to run it.

I was thinking of a "U-Boot only" procedure, like md.b (to run on the source board) and cp.b (to run on the destination board). In this way I must copy&paste the md.b text result from the terminal to a file, process it (on the computer) to have a binary content of the environment, download (by TFTP) it on the destination board and run cp.b. What do you think about this procedure?

Another possibility is to printenv on the source board, copy the text result from the terminal into a text file, append "setenv " at the top of each lines, substitute = character with space, insert the quotes where needed and paste the result in the terminal of the destination board.

On 30 Dec 2008 at 12:40, Alessandro Rubini wrote:

...

So you're proposing to use Linux to copy U-Boot environment. But on a new board (picked from the shelf) I don't have Linux and I should set some U-Boot variables to run it.

So you might prefer setting them as predefined in you configuration file, so when the u-boot binary finds no environment on flash (crc error) and it will use those values, until you saveenv new values.

I don't like to change U-Boot default configuration. The U-Boot environment changes project by project. I want to avoid recompiling U- Boot for each project. I'd like to have a single U-Boot application and different environment saved as files.

...

I was thinking of a "U-Boot only" procedure, like md.b (to run on the source board) and cp.b (to run on the destination board).

You can unprotect, erase, and cp.b to the flash sector(s), once you have the binary image of the environment. You can extract such image from /dev/mtd in the running board and then use tftp (as you suggested) on the new board.

Yes, I think that is my way. Thank you all.

Best regards, Giuseppe Modugno

On 30 Dec 2008 at 22:42, Wolfgang Denk wrote:

It is difficult to make recommendations when you're providing inconsistent input. In your previous message you wrote:

...

...

I have a board running U-Boot/Linux. U-Boot program, two U-Boot environments, Linux kernel and root filesystem for Linux are stored in a NOR Flash.

Now you claim "I don't have Linux".

Can you please decide whether or not you have Linux running on that board?

I'm sorry for the misunderstanding.

Linux really runs on my board, but only after I store the kernel and the root filesystem on the Flash memory. And to do these operations, I must have a good U-Boot environment.

So I have a source board with a good U-Boot environment and Linux, and a destination board (picked from the shelf) with just U-Boot and its default environment (no Linux runs on it).

I can copy the good U-Boot environment from the source board to a file by using Linux, but I can't use Linux on the destination board to store the good environment in the memory.

I think the best solution is to use Linux on the source board to copy the good U-Boot environment in a image file. On the destination board, I can download (by tftp) the image and store it on the Flash at the correct address. In this way, I'll use only U-Boot on the destination board to retrieve the good environment. From that, I can install kernel and root filesystem.

...

Another possibility is to printenv on the source board, copy the text result from the terminal into a text file, append "setenv " at the top of each lines, substitute = character with space, insert the quotes where needed and paste the result in the terminal of the destination board.

You could (and probaly should) put the constant part of your definitions into the default environment, and use a script image for the rest.

Just now I'm reading about the scripting capabilities of U-Boot. It's interesting. Starting from which U-Boot version they are available?

Just another question. I have two redundant U-Boot environments. Should I copy both of them in two different images, or are they the same and I can copy the first into the second?

Regards, Giuseppe

Dear Giuseppe Modugno,

...

I think the best solution is to use Linux on the source board to copy the good U-Boot environment in a image file. On the destination board, I can download (by tftp) the image and store it on the Flash at the correct address. In this way, I'll use only U-Boot on the destination board to retrieve the good environment. From that, I can install kernel and root filesystem.

No, that is not a good idea, as this way you would also copy board-specific settings lime serial number, MAC address etc.

...

I also have such a requirement. So what I am doing is that the variables that is common to all boards are kept as a script which my terminal program (used to access serial port) can run. So in the first boot, all these variables plus the board specific things like serial number, MAC address, etc. will be set and saved to flash.

Regards, Jayakrishnan