Dear Aaron Williams,
In message 201102081927.36497.Aaron.Williams@caviumnetworks.com you wrote:
...
memory size to CONFIG_MAX_MEM_MAPPED. This won't work for us. As I said, we need to move it out of the lower 4GB when there's more memory involved. We also don't
Why?
As I have said, we need all of the lower portion of memory and do not want to introduce holes in the memory space for u-boot for loading 64-bit
When I ask "why?" then I do so to understand the reasons fdor your design decisions (and eventually to be able to recomment alternative solutions).
In such a situation phrases as "we need" or "we [do not] want" are completely useless und unhelpful, unless they are accompanied with a "because ..." part that explains _why_ you [think you] "need" or "want" these things.
I understand that you do not _want_ to change this. My question is: what would you do if you _had_ to change it?
We might be able to make some changes, but it might be difficult since we have a lot of developers working on this around the world. I would prefer to not have to maintain two separate code bases. I will need to see how much I can strip out.
Well, frankly, this is your problem, not ours. If Cavium had decided to discuss the design early we might have come up with a solution that fits without too much problems. Instead, Cavium went on and kept their stuff closed for years - now they say that it's difficult to change things. Please understand that our foxus is on the overall quality and maintainability of the code, so such arguments do not carry much weight.
since there is some dependency on some of the include files from our GCC distribution as well, plus our toolchain distribution includes support for some of the extensions we make use of.
Can this be fixed? I mean, copying some header files should probably be a solvable problem. What about of these "extensions" - are they absolutely needed in U-Boot? Usually such extensions are either performance optimizations which are not really needed in U-Boot, or other well-localized operations that can b ehandlef with small assembler stubs.
Support for our Octeon2 processor is not in the mainline trunk yet. We also have some changes needed to work with our SDK and the Linux kernel with our newer chips.
You reply, but you do not actually answer my questions.
In general we do not want to see board or SoC specific changes to common code.
The common code is already chock full of them from what I've seen in a number
Yes, and we've learned that lesson, and now we strive hard not to add to the mess any more.
of areas. The number of changes for our SoC is actually quite small. In some cases I've just changed some functions to use __attribute__((__weak__)) so we can define the functionality elsewhere. I count a total of 21 ifdefs in the common code, most of those are in cmd_ide.c, one in cmd_boot.c, one in cmd_elf.c, two in env_flash.c and some in main.c, which can be removed (those are for adding the support for dynamically changing the boot prompt) and one in miiphyutil.c. Right now cmd_ide.c can be cleaned up a bit. The problem is that cmd_ide.c includes the driver functionality in it, requiring us to do this. I can clean this up by making some of the functions weak. Is this reasonable?
I don't know. I haven't seen any of the code yet, so I really cannot tell.
One other change I had to make was for the command table. I have to force the alignment to 8 bytes in the compiler or very bad things happen.
Why?
Best regards,
Wolfgang Denk