[U-Boot] U-boot Porting

[Daniel Schwierzeck]

Hi Aaron,

2012/7/6 Aaron Williams <Aaron.Williams at cavium.com>:
> Hi Andreas,
>
> I would love to see OCTEON support in the mainline as well, though I am not
> sure how I should go about this since it is a substantial amount of code.
> Fortunately most of the changes are not to the common code, and many of the
> common code changes are feature enhancements portable to other platforms as
> well.

we should do this step by step. My suggestions are:

1) send a patch series with only the changes on MIPS common code. I
assume that you updated most of the header files
with the current ones from linux? I am currently working on extending
the support for MIPS32 CPUs thus we should unify the common
MIPS code base at first.

2) send a patch series with only basic support for Octeon and provide
a toolchain for free download. This allows us to do build tests.

3) send patches for all minimum required Octeon drivers and common
code changes to make mainline U-Boot working on real hardware

4) send patches for additional drivers and features

>
> One big problem I have is I have no way of testing any of my stuff on
> non-Cavium boards or CPUs so testing my changes and making sure I didn't
> break anything is rather difficult.

I think that is no big problem. I can test MIPS specific changes on
MIPS32 machines and QEMU.
Changes to common code are reviewed by and tested by the according maintainers.
At least you have to do compile tests as described here:
http://www.denx.de/wiki/view/U-Boot/Patches#Notes

> I am also not too familiar with git or
> how to actually submit the patches with it though I can work with our Linux
> kernel developer on this.
>
> When I redid U-Boot using the up-to-date code I made a large effort to keep
> our stuff separate from the rest of the U-Boot code so much of our stuff is
> fairly well isolated. I placed most of our code under arch/mips/cpu/octeon
> and arch/mips/include/asm/arch-octeon (though some of the files in
> arch/mips/include/asm also had to be changed). Most of the rest of the code
> is in board/octeon/xxx though there's a fair amount in board/octeon/common.

Sounds good. Maybe you should use board/cavium/xxx instead because the
directories in board/
reflect either the board name or the vendor name.

<snip>

> We have little in common with the other MIPS processors since we have to
> support 64-bit mode. To do this we compile it with our own toolchain using
> the N32 ABI. I believe most of our changes are now in the mainline GCC as
> well now.
>
> We also do not use arch/mips/lib/board.c since our version is so different.
> I will be the first to admit that the code needs to be cleaned up since
> board_init_f is huge.

actually that is not a problem. What about arch/mips/lib/bootm.c?

Best regards,
Daniel