Hi,

Just as a follow up, I conclude that U-boot treats flash reads exactly as sdram reads i.e. 32-bit accesses. So its not just about the environment variables. Most of the flash-based U-boot functionality wouldn't work for us unless we modify all the commands that have access to flash e.g md, imiinfo, bootm etc. A hardware fix (an 8-bit bus to our byte-mode flash chip) seems like the right way to go.

Shamile

On Sat, 2004-01-31 at 12:12, Wolfgang Denk wrote:

In message 1075423717.18221.233.camel@localhost.localdomain you wrote:

...

To get around this, we have a small program which is stored in FPGA bitstream and runs in FPGA on-chip memory (called BRAM). This program copies u-boot binary image from flash to sdram and jumps to it. This allows U-boot to run. However the problem is that the environment variables saved in flash are not being used even though U-boot has been configured with the CFG_ENV_IS_IN_FLASH option turned on. CFG_FLASH_BASE has been set to the flash base address of u-boot and when I use saveenv the environment is saved at the proper offset CFG_ENV_OFFSET. The only thing thats a bit different for my U-boot configuration is that CFG_MONITOR_BASE is set to the sdram base address where U-boot starts executing from instead of being set to CFG_FLASH_BASE.

Normally U-Boot attempts to read the environment when starting from the same position in memory where it will save it to when you issue a "saveenv" command. You will have to modify U-Boot such that the initialization reads from the "fixed" copy in RAM, while "saveenv" saves to the address in flash, performing the 16-bit-expansion needed for your setup. It seems obvious that a plain copy as usuall cannot work on your system.

Best regards,

Wolfgang Denk

-- See us @ Embedded World, Nuremberg, Feb 17 - 19, Hall 12.0 Booth 440 Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de Drun'? 'm not drun'! You woudn' dare call m' drun' if I was sober! - Terry Pratchett, _Men at Arms_

On Wed, 2004-02-04 at 15:30, Wolfgang Denk wrote:

In message 1075855660.7664.95.camel@localhost.localdomain you wrote:

...

Just as a follow up, I conclude that U-boot treats flash reads exactly as sdram reads i.e. 32-bit accesses. So its not just about the

This is not correct.

U-Boot accesses the flash just the way how you configure your memory controller for flash accesses.

Exactly. The memory controller is in FPGA. Its been configured to have a data bus width of 8 bits to the flash memory device. Consequently if a 32 bit access is requested, the first 8 bits are fine and the rest are garbage.

...

to flash e.g md, imiinfo, bootm etc. A hardware fix (an 8-bit bus to our byte-mode flash chip) seems like the right way to go.

Either you or me must be missing something. Why don't you just configure U-Boot for a 8 bit flash device then?

I do have the flash device configured as an 8-bit device and flash memory writes are for byte mode in the flash driver. So writes to flash are fine as long as I use cp.b instead of just cp.

As far as reads are concerned, since the flash device is in byte mode I can only access 8 bits in one flash memory read cycle. However U-boot commands like md, bootm, iminfo, crc32 etc access 32 bits in one flash memory read cycle (md.b is an exception).

So those commands would work if I have for example 4 byte-mode flash devices and the memory controller concatenates the data thats read from those devices. But I only have one byte-mode flash device.

Best regards,

Wolfgang Denk

-- See us @ Embedded World, Nuremberg, Feb 17 - 19, Hall 12.0 Booth 440 Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de Real Programmers always confuse Christmas and Halloween because OCT 31 == DEC 25 ! - Andrew Rutherford (andrewr@ucs.adelaide.edu.au)