[U-Boot] Some notes and status on porting U-Boot to the Cavium 64-bit Octeon MIPS Processor

[Wolfgang Denk]

Dear Aaron Williams,

In message <201102071524.17440.Aaron.Williams at caviumnetworks.com> you wrote:
>
> > these.  I understand that you are using a 64 bit port of U-Boot?
> 
> No. We are using a 32-bit port since I think trying to make a 64-bit port of 
> U-Boot would be far more involved. We do have support for loading and 
> executing 64-bit ELF images, however. We use special memcpy/memset functions 
> for 64-bit memory addressing in these cases.

OK, let's discuss this when we see your code.

> > Existing U-Boot deals with this by mapping just the lower and the
> > upper parts of available physical memory. See the CONFIG_VERY_BIG_RAM
> > config option.
> > 
> I just looked at this and this. The only place I see this used is in 
> arch/powerpc/lib/board.c and it looks like it just limits the effective memory 
> size to CONFIG_MAX_MEM_MAPPED. This won't work for us. As I said, we need to 
> move it out of the lower 4GB when there's more memory involved. We also don't 

Why?

> want there being holes in the middle of the memory if we can help it, nor do 
> we want to place u-boot at the lower end of memory. At least on MIPS the TLB 

The question is what is the lesser of two evils: not mapping all of
the available memory and stick with a total of mapped memory that is
addressable in 32 bit adress space, or adding the complexity to deal
with 64 bit address spaces - which will require changes in _lots_ of
places.

But again I suggst to defer the discussion until we see your code.

> Would using virt_to_bus to convert pointers to DMA addresses be appropriate 
> instead of the current assumption that pointers can be used as DMA addresses 
> directly? This seems like a portable solution since on platforms where the 
> pointer and DMA address are the same the macro would just do nothing. Even if 
> we didn't use virtual addresses and were using, say, KSEG1 the pointer and 
> physical address don't match.

Yes, I think this would indeed be a better approach.

> > Do I understand correctly t hat this SDK (whatever that might be) will
> > then have to be included with the U-Boot distribution?
> > 
> > What would be alternatives to static linking, such as to avoid adding
> > all this code?
> > 
> It would have to be included only for the Octeon processors. It is statically 

I don't undertsand what you mean. Either it is part of the U-Boot
source tree, or it is not.  You cannot add it "only for the Octeon
processors" - either it's there, or it ain't.

Given that we are talking about code in the order of 30% of the total
U-Boot code, probably not conforming to U-Boot coding standards, I am
anything but happy about such an addition.  Assume ever SoC vendor
comes up with similar ideas...

> linked and we don't want to get away from this. Also, some of our u-boot files 
> are in turn statically linked against some of our utilities, such as our 

I understand that you do not _want_ to change this.  My question is:
what would you do if you _had_ to change it?

> Also note that u-boot for Octeon can only be compiled with our toolchain, 
> since there is some dependency on some of the include files from our GCC 
> distribution as well, plus our toolchain distribution includes support for 
> some of the extensions we make use of.

Can this be fixed?  I mean, copying some header files should probably
be a solvable problem.  What about of these "extensions" - are they
absolutely needed in U-Boot?  Usually such extensions are either
performance optimizations which are not really needed in U-Boot, or
other well-localized operations that can b ehandlef with small
assembler stubs.


> > Such general changes should then NOT use CONFIG_OCTEON, but some
> > generic variable name.
> > 
> I agree, though some many cases they are not general, such as some of the 
> support for our compact flash in cmd_ide.c and a few other areas.

In general we do not want to see board or SoC specific changes to
common code.

> > Many boards use board specific commands; I see no problem with having
> > SoC specific commands either.
> 
> I am placing these commands under arch/mips/cpu/octeon/commands rather than 
> clutter up the common code, unless you feel it's better to put all the 
> commands under the common code.

This sounds OK with me.

> > > I don't think I can include our SDK as a series of patches on the mailing
> > > list since it is about 26MB with some of the hardware generated files
> > > being hundreds of kilobytes to 12MB for our register database file
> > > (which fortunately isn't needed by u-boot!) It's available under the
> > > LGPL but not easily accessible through our open-source web site without
> > > registration :(
> > 
> > U-Boot is supposed to be self-sufficient, i. e. to contain all parts
> > that are required to build a working U-Boot image.  I see a potential
> > area of conflicts here.
> 
> We don't have any problem including our SDK with U-Boot. I can work on trying 

But  we probably will have problems adding tons of such code which is
of no use to anybody else.

> The biggest portions of our SDK are generated files for dealing with errors,  
> a register database (12MB!) and include files which define access functions to 

I'd expect that only a tiny percentage of this is actually needed /
used in U-Boot.  We should restric it to these actually used parts.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"We don't have to protect the environment -- the Second Coming is  at
hand."                                                   - James Watt