Dear Allen,

please keep the u-boot-users list Cc:ed.

In message FA06AA2C99BCD511951200005A99441003BE1706@IRVEXCH1 you wrote:

I am sorry about the format. Between fighting the corporate IT guys and Windoz I feel lucky that it works at all.

It's not usable, though. We need context or unified diff's or any simple change elsewhere in the file (which causes the line numbers to shift) will break it.

...

< $(OBJCOPY) -O binary $< $@ 2>/dev/null

...

  $(OBJCOPY) -O ppcboot $< $@ 2>/dev/null

Please explain why. Does the MontaVista version of the binutils doe not understand "binary" output format any longer?

The MontaVista tools will not convert binary to srec. You get an error message about unknown architecture. However I discovered the ppcboot options which works fine. Another solution is to use "dd" to strip the 64k header.

Well, this is a bug in the MV toolchain then. Complain at MV. We will NOT add this to the Makefile as it breaks all other systems.

...

Index: board/mpc8266ads/config.mk

RCS file: /cvsroot/u-boot/u-boot/board/mpc8266ads/config.mk,v retrieving revision 1.2 diff -r1.2 config.mk 30c30

< TEXT_BASE = 0xfe000000

...

TEXT_BASE = 0xfff00000

Please explain why you think this is necessary.

The reset vector for 8260 is 0xfff00100. The easiest way to u-boot to put code at this location is to change TEXT_BASE. This is the same as the MPC8260 config.mk file....

There is no relation between the reset vector and TEXT_BASE. You can have the reset vector at 0x100 and TEXT_BASE - say - at 0x40000000. I don't think I want to change this configuration (which seems to be working to several people) without a really good reason.

...

diff -r1.4 MPC8266ADS.h 236,237c236,237 < #define CFG_FLASH_BASE 0xFE000000

< #define FLASH_BASE 0xFE000000

...

#define CFG_FLASH_BASE 0xFF800000 #define FLASH_BASE 0xFF800000

252,253c252,253 < #define CFG_BCSR 0xF8000000 < #define CFG_PCI_INT 0xF8200000 /* PCI interrupt

controller

...

*/

...

#define CFG_BCSR 0x04500000 #define CFG_PCI_INT 0x04730000 /* PCI interrupt

controller */

Please explain why you think this is necessary.

FLASH_BASE 0xff800000 - the board ships with a 8MB SIMM. This is the base address.

You can map the flash at any arbitrary address. I don't see why 0xFF800000 would be any better than 0xFE000000 - on contrary - mapping it at 0xFE000000 leaves enough room if there should ever be a board with bigger flash chips.

CFG_BCSR & CFG_PCI_INIT - according to the memory map in the MPC8266ADS manual, these are the physical addresses. You need to access the BCSR to enable the serial and Ethernet ports.

Physical addresses on a 82xx are programmable. The programming of the memory controller decides where a device shows up in the physiacal memory map. Please ignore the memory map given in the manyal - it is just one example out of many possible, and it is an example which will NOT work with Linux.

Actually I think it is a bug to map the BCSR at a low address like 0x04500000. Are you really, really sure that this will work with Linux?

Virtual address != Physical address These are correct according to the documentation

You are wrong. There are certain address ranges in Linux which are mapped with virtual"physical 1:1. The IMMR and BCSR areas are among them.

This works. The current u-boot implementation does not work. Perhaps the current configuration works with a different board configuration. If that is true, then there should be a big note somewhere with detailed configuration notes.

I doubt that you have any Linux applications running with your configuration.

Rune, are you reading this? I don't have a MPC8266ADS board to actually test this, but you are the board maintainer. What is your comment?

Best regards,

Wolfgang Denk