Hi Daniel,
My comments are inline.
On 07/09/2012 02:11 PM, Daniel Schwierzeck wrote:
Hi Aaron,
2012/7/6 Aaron Williams <aaron.willi...@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)
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
