[U-Boot-Users] [PATCH] 405 OCM warning

[Wolfgang Denk]

In message <20040702074111.GB32518 at pengutronix.de> you wrote:
>
> But U-Boot initializes CFG_OCM_DATA_ADDR. When I started with the 405
> port I had this macro pointing to 0x4000'0000 which is right in the

I guess you had a special reason to do this when all other boards use
either 0xF0000000 (4 boards)  or  0xF8000000  (17  boards)  for  this
definition.

> middle of the Linux user space task virtual address range. I doubt that
> the kernel makes a 1:1 mapping for this memory area ;) I don't have the
> 405 manual here for reference, but if I remember correctly it was the
> virtual address you could configure here. Although this is not directly

I think this is the relevant part:

        "If address translation is enabled (MSR[IR,DR] = 1), one or
        more TLB entries for the OCM address space must exist to
        validate accesses. However, the virtual addresses are _not_
        translated, and 32 bit effective addresses (virtual
        addresses) are presented to the OCM."

So basicly you have a 1:1 mapping here: virtual addresses are  passed
through to the OCM's address range compare registers 1:1.

> a problem which influences U-Boot it should IMHO be noted in the
> description of U-Boot's config variable that this is dangerous, and not
> only with Linux. 

It is not exactly dangerous, just inappropriate for certain uses.

Setting up the memory map of a system requires a  lot  of  experience
and  detailed  knowledge  about  both  the  hardware and the software
architecture of the whole system. For example, mapping  the  IMMR  of
8xx  or 82xx processors to - say - 0x04700000 like some board vendors
do in their documentation is perfectly OK for  some  purposes  -  and
U-Boot was running perfectly fine on the MPC8260ADS which used to use
such  a  setting  for a long time. Also, some other RTOS work fine in
such a configuration. Linux will crash.

So what is really needed is some kind of Linux porting documentation,
i. e. a list of requirements for boot loaders - similar to  the  "ARM
Linux Kernel Boot Requirements"
(http://www.arm.linux.org.uk/developer/booting.php),
probably extended by hints about memory mapping issues, etc.


To make the long storey short: CFG_OCM_DATA_ADDR is just one of  many
parameters which can be set wrong, resulting in a system which either
does  not  work aty all or crashes in most funny ways. I agree that a
hint about potential problems is  appropriate,  but  then  we  should
probably  add a separate file in the doc/ directory for such critical
settings.

My main concern and the reson why I rejected this patch again is  the
wording:  the  text "the ... (OCM) is mapped on virtual addresses" is
not correct, and misleading to the  reader  especially  since  U-Boot
does not use any virtual memory.

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
Beware of the Turing Tar-pit in  which  everything  is  possible  but
nothing of interest is easy.