[U-Boot-Users] MPC8266ADS patch

[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 at 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Status quo. Latin for "the mess we're in."