Dear Aaron,
In message <4ffcaf12.1030...@cavium.com> you wrote:
>
> 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.
We spend a lot of time here discussiong thaings that you have done and
how easy it will be to merge these into mainline. I think we are
wasting time here. Instead of much further ado, you should just start
posting the first small sets of these easy to merge patches, so we can
really see if they go in that easily.
> 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.
Obviouslye we need a way to test the code so we can be sure it is at
least compile-clean. So the availability of a tool chain is somethign
that needs to be solved first.
> 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.
See recent discussion about location of drivers.
> 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 hav eno idea what your SDK is or does, but the code you submit
should stick to the established rules.
> 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
Are there any other vendors manufacturing or selling Octeon chips?
The directory structure in U-Boot is board/<vendor_name>/... , not
board<chip_family_name>/ , so this shoud be changed into board/cavium/
> 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.
You can always set up something as
board/cavium/octeon_common/
board/cavium/octeon_board_foo/
board/cavium/octeon_board_bar/
board/cavium/arm_common/
board/cavium/arm_board_foo/
board/cavium/arm_board_bar/
etc. But the vendor part pf the directory path should match the
vendor name, and not be something different.
> 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.
Integrate this into mkimage ?
> 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.
Hm... given yourprevious explanations, I expect that some significant
efforts will be needed (on all sides) to get this stuff mainlined.
I recommend you make sure someone at Cavium has sufficient resources
to handle this, otherwise it's likely to be a frustrating experience
on both sides.
Best regards,
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: w...@denx.de
"The whole problem with the world is that fools and fanatics are
always so certain of themselves, but wiser people so full of doubts."
- Bertrand Russell
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
