[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 <201102081927.36497.Aaron.Williams at caviumnetworks.com> you wrote:
>
...
> > > 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?
> 
> As I have said, we need all of the lower portion of memory and do not want to 
> introduce holes in the memory space for u-boot for loading 64-bit 

When I ask "why?" then I do so to understand the reasons fdor your
design decisions (and eventually to be able to recomment alternative
solutions).

In such a situation phrases as "we need" or "we [do not] want" are
completely useless und unhelpful, unless they are accompanied with a
"because ..." part that explains _why_ you [think you] "need" or
"want" these things.

> > I understand that you do not _want_ to change this.  My question is:
> > what would you do if you _had_ to change it?
> 
> We might be able to make some changes, but it might be difficult since we have 
> a lot of developers working on this around the world. I would prefer to not 
> have to maintain two separate code bases. I will need to see how much I can 
> strip out.

Well, frankly, this is your problem, not ours. If Cavium had decided
to discuss the design early we might have come up with a solution
that fits without too much problems. Instead, Cavium went on and kept
their stuff closed for years - now they say that it's difficult to
change things. Please understand that our foxus is on the overall
quality and maintainability of the code, so such arguments do not
carry much weight.

> > > 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.
> 
> Support for our Octeon2 processor is not in the mainline trunk yet. We also 
> have some changes needed to work with our SDK and the Linux kernel with our 
> newer chips.

You reply, but you do not actually answer my questions.


> > In general we do not want to see board or SoC specific changes to
> > common code.
> 
> The common code is already chock full of them from what I've seen in a number 

Yes, and we've learned that lesson, and now we strive hard not to add
to the mess any more.

> of areas. The number of changes for our SoC is actually quite small. In some 
> cases I've just changed some functions to use __attribute__((__weak__)) so we 
> can define the functionality elsewhere. I count a total of 21 ifdefs in the 
> common code, most of those are in cmd_ide.c, one in cmd_boot.c, one in 
> cmd_elf.c, two in env_flash.c and some in main.c, which can be removed (those 
> are for adding the support for dynamically changing the boot prompt) and one 
> in miiphyutil.c. Right now cmd_ide.c can be cleaned up a bit. The problem is 
> that cmd_ide.c includes the driver functionality in it, requiring us to do 
> this.  I can clean this up by making some of the functions weak. Is this 
> reasonable?

I don't know. I haven't seen any of the code yet, so I really cannot
tell.

> One other change I had to make was for the command table. I have to force the 
> alignment to 8 bytes in the compiler or very bad things happen.

Why?


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
Let the programmers be many and the managers few -- then all will  be
productive.               -- Geoffrey James, "The Tao of Programming"