[U-Boot-Users] [PATCH] 405 OCM warning
wd at denx.de
Fri Jul 2 11:55:18 CEST 2004
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
> 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"
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
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.
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.
More information about the U-Boot