[U-Boot] [EXT] Re: Cavium/Marvell Octeon Support

[Wolfgang Denk]

Dear Aaron,

In message <4176494.JIoP81OjG2 at flash> you wrote:
>
> Actually the low level code is significantly different. First of all, we need 
> the U-Boot bootloader to be able to boot from different memory locations. 
> Because of this, we use mapped memory for U-Boot. A side effect of this is 
> that it eliminates the need for relocation when it is shifted to the top of 
> memory. All we need to do is just set a couple of TLB entries.
>
> The assembly code is significantly different and is far more extensive.
>
> Additionally, the way Octeon Linux is booted is different.
>
> The generic start.S is not usable in our case.

Please excuse my ignorance - I have never touched a Cavium system yet
(at least not knowingly), and never looked into any of that code.
So for me it would be really helpful if you would not only describe
what you have, or what you need, or that things are different or
cannot be used, but actually explain _why_ this is the case, and why
you cannot use the existing structure of U-Boot mainline code.

I know that it is always difficult to upstream code that has been
developed out of tree and without synchronizing the design with the
mainline maintainers, but as long as you don't explain why it was
mandatory to do things different, it is impossible to understand if
this is the only sane way things can be implemented, or if you just
don't want to change the code that has grown over the years in an
uncontrolled way to avoid the efforts for cleaning it up.

> We have a significant amount of code for dealing with the cache and for things 
> like copying U-Boot from flash into the L2 cache. We also have to deal with 
> taking other cores out of reset in our start.S. Our exception handler has also 
> been extended to handle multiple cores.

We should be able to understand why you need this.  There might be
areas where your code overlaps with things that are already
available in U-Boot mainline, and if there are good reasons to
duplicate such areas, you should explain them.

Daniel already pointed out that doubling the code size of U-Boot by
adding just a single new CPU simply makes no sense.  I don't know
what you are using U-Boot for, but we should keep in mind that it's
a boot loader, which main purpose should be to execute as fast as
possible just to be replaced by an operating system.

I have to admit that I have problems understanding why someone would
need hot plug support for hardware in U-Boot.

It would be best to restrict initial upstreaming to a minimal sub-set
that gives maintainers even a chance to review it.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
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
Alliance: In international politics, the union  of  two  thieves  who
have  their hands so deeply inserted in each other's pocket that they
cannot separately plunder a third.                   - Ambrose Bierce