[U-Boot] U-boot Porting

[Aaron Williams]

Hi Daniel,

My comments are inline.

On 07/09/2012 02:11 PM, Daniel Schwierzeck wrote:
> 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.
I made a number of additions to the header files. For the most part I 
did not update them from Linux but modified the existing ones. I tried 
to keep my changes minimal. As I said I use board_octeon.c instead of 
board.c. I have wrapped all of our changes with #ifdef CONFIG_OCTEON.

It should be fairly easy to do this.

>
> 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.
GCC as of version 4.7 should work. Note that for OCTEON we compile using 
the N32 ABI instead of O32. Doing "basic" OCTEON support will not be 
easy since there is a huge dependence on our SDK.
>
> 3) send patches for all minimum required Octeon drivers and common
> code changes to make mainline U-Boot working on real hardware
The only required drivers are the MDIO drivers. Most of the other 
drivers, i.e. Ethernet, PCI, I2C, serial, flash, NAND and watchdog are 
located under arch/mips/cpu/octeon. I don't know if it makes sense to 
move these into the drivers tree since these are specific to OCTEON and 
some (i.e. the Ethernet driver and NAND) have a strong dependency on our 
SDK.
>
> 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'll try this. I have been enforcing the U-Boot coding standard and 
recently we switched our SDK to follow that (though our SDK does not 
honor the 80 column limit).
>> 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.
We do that. We use board/octeon/xxx for everything right now including 
all of our vendors since the boards all have dependencies on 
board/octeon/common. Because we had a problem with vendors just 
modifying an existing board and complaining when we did a new release I 
created a script to assist in adding a new board which uses this 
directory. I would rather use octeon instead of cavium since we also 
have several ARM based chips with more to follow.
> <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
>
The only change I made to bootm.c is that for OCTEON we don't have 
uncached memory. On the OCTEON processor, all DRAM is cached (and the L1 
data and L2 caches are coherent).

I know that some of the code will need to be cleaned up. Our 
board_octeon.c has grown into a big mess that could use some serious 
clean-up.

We also have added some tools for U-Boot. One tool generates a special 
header for U-Boot which contains a CRC and other information.

Unfortunately I will not have a lot of time in the near future since I 
need to do some work on Valgrind. I can try and create a patch for the 
header files and bootm.c, though.

-Aaron

-- 
Aaron Williams
Software Engineer
Cavium, Inc.
(408) 943-7198  (510) 789-8988 (cell)