RE: [U-Boot-Users] MPC8266ADS patch
< $(OBJCOPY) -O binary $< $@ 2>/dev/null
$(OBJCOPY) -O ppcboot $< $@ 2>/dev/nullPlease 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.
My suggestion was to add this as a comment to the Makefile.
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.
The reset address is either 0x00000100 or 0xfff00100. The current u-boot configuration doesn't locate any code at these locations. The MPC8260 configuration specified TEXT_BASE as 0xfff00000 and it works. The current u-boot configuration does not boot.
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.
As long as something responds to the 0xfff00xxx address range you are correct.
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.
If the only hardware requirement is chip-select generation, this is correct. It would be better to move these to another location.
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 is very implementation specific. There have been several discussions about the use of BATs with these architectures.
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.
I see Linux and u-boot as two very different things. In my opinion it is useful to have the BIOS follow the documented configuration. This helps the person who is trying to bring up, and probably learn, a new platform. As they become comfortable with the hardware they can deviate from the standard configuration. The difference is that they made those changes and didn't need to refer to several documents (or source code) to figure out a memory map. When Linux boots, it assumes the BIOS is brain-dead and reconfigures everything. The BCSR and IMMR will be relocated to what makes sense for that operating environment.
In message FA06AA2C99BCD511951200005A99441003BE170A@IRVEXCH1 you wrote:
I see Linux and u-boot as two very different things. In my opinion it is useful to have the BIOS follow the documented configuration. This helps the person who is trying to bring up, and probably learn, a new platform. As they become comfortable with the hardware they can deviate from the standard configuration. The difference is that they made those changes and didn't need to refer to several documents (or source code) to figure out a memory map. When Linux boots, it assumes the BIOS is brain-dead and reconfigures everything. The BCSR and IMMR will be relocated to what makes sense for that operating environment.
I think it is better to set up a useful and working memory map in the first place. YMMV.
Best regards,
Wolfgang Denk
Dear Curtis,
first: can you please try to properly quote text included from previous messages? In your posting both your and my text follow interleaved without any marker who wrote what. This is difficult to read for myself (and I remeber what I wrote), but it is impossible to read for others (and it's bad style anyway).
In message FA06AA2C99BCD511951200005A99441003BE170A@IRVEXCH1 you wrote:
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.
The reset address is either 0x00000100 or 0xfff00100. The current u-boot configuration doesn't locate any code at these locations. The MPC8260 configuration specified TEXT_BASE as 0xfff00000 and it works. The current u-boot configuration does not boot.
I think you should re-read the section of the processor's user manual about the operation of the memory controller after reset. And it obviously works for the board maintainer plus some other folks.
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.
As long as something responds to the 0xfff00xxx address range you are correct.
After reset it will. RTFM.
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 is very implementation specific. There have been several discussions about the use of BATs with these architectures.
Maybe there were discussions. I don't care. Fact is that the current code requires such a 1:1 mapping, so U-Boot will provide it. It makes no sense to create a configuration that matches some documentation (which uses an arbitrary memory map which is not better than any other memory map) if the result is a firmware that will not be able to boot U-Boot.
For me, the most important thing is that it works. Then it must be clean and technically elegant. The memory map in some unrelated documentation does not play a role in any of these decisions.
I doubt that you have any Linux applications running with your configuration.
I see Linux and u-boot as two very different things. In my opinion it is
You can see it as you like.
But I will not intentionally create a configuration of U-Boot that cannot boot existing Linux kernel code.
useful to have the BIOS follow the documented configuration. This helps the person who is trying to bring up, and probably learn, a new platform. As
It is much more helpful for the person who is trying to bring up a board to try to understand what he is doing, instead of taking one example as God-given and immutable.
configuration. The difference is that they made those changes and didn't need to refer to several documents (or source code) to figure out a memory map. When Linux boots, it assumes the BIOS is brain-dead and reconfigures everything. The BCSR and IMMR will be relocated to what makes sense for that operating environment.
This is NOT correct in current versions of the Linux kernel. At least NOT on PowerPC systems.
Let's stop this fruitles discussion here. The board maintainer configrmed that the current configuration is actually working, and your suggestions are obviously wrong as they will break Linux support.
Your patch was rejected, and this is my final decision on that subject.
Best regards,
Wolfgang Denk
participants (2)
-
Curtis, Allen -
Wolfgang Denk