Dear Aaron Williams, In message <201102071524.17440.aaron.willi...@caviumnetworks.com> you wrote: > > > these. I understand that you are using a 64 bit port of U-Boot? > > No. We are using a 32-bit port since I think trying to make a 64-bit port of > U-Boot would be far more involved. We do have support for loading and > executing 64-bit ELF images, however. We use special memcpy/memset functions > for 64-bit memory addressing in these cases.
OK, let's discuss this when we see your code. > > Existing U-Boot deals with this by mapping just the lower and the > > upper parts of available physical memory. See the CONFIG_VERY_BIG_RAM > > config option. > > > I just looked at this and this. The only place I see this used is in > arch/powerpc/lib/board.c and it looks like it just limits the effective > 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? > want there being holes in the middle of the memory if we can help it, nor do > we want to place u-boot at the lower end of memory. At least on MIPS the TLB The question is what is the lesser of two evils: not mapping all of the available memory and stick with a total of mapped memory that is addressable in 32 bit adress space, or adding the complexity to deal with 64 bit address spaces - which will require changes in _lots_ of places. But again I suggst to defer the discussion until we see your code. > Would using virt_to_bus to convert pointers to DMA addresses be appropriate > instead of the current assumption that pointers can be used as DMA addresses > directly? This seems like a portable solution since on platforms where the > pointer and DMA address are the same the macro would just do nothing. Even if > we didn't use virtual addresses and were using, say, KSEG1 the pointer and > physical address don't match. Yes, I think this would indeed be a better approach. > > Do I understand correctly t hat this SDK (whatever that might be) will > > then have to be included with the U-Boot distribution? > > > > What would be alternatives to static linking, such as to avoid adding > > all this code? > > > It would have to be included only for the Octeon processors. It is statically I don't undertsand what you mean. Either it is part of the U-Boot source tree, or it is not. You cannot add it "only for the Octeon processors" - either it's there, or it ain't. Given that we are talking about code in the order of 30% of the total U-Boot code, probably not conforming to U-Boot coding standards, I am anything but happy about such an addition. Assume ever SoC vendor comes up with similar ideas... > linked and we don't want to get away from this. Also, some of our u-boot > files > are in turn statically linked against some of our utilities, such as our I understand that you do not _want_ to change this. My question is: what would you do if you _had_ to change it? > Also note that u-boot for Octeon can only be compiled with our toolchain, > 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. > > Such general changes should then NOT use CONFIG_OCTEON, but some > > generic variable name. > > > I agree, though some many cases they are not general, such as some of the > support for our compact flash in cmd_ide.c and a few other areas. In general we do not want to see board or SoC specific changes to common code. > > Many boards use board specific commands; I see no problem with having > > SoC specific commands either. > > I am placing these commands under arch/mips/cpu/octeon/commands rather than > clutter up the common code, unless you feel it's better to put all the > commands under the common code. This sounds OK with me. > > > I don't think I can include our SDK as a series of patches on the mailing > > > list since it is about 26MB with some of the hardware generated files > > > being hundreds of kilobytes to 12MB for our register database file > > > (which fortunately isn't needed by u-boot!) It's available under the > > > LGPL but not easily accessible through our open-source web site without > > > registration :( > > > > U-Boot is supposed to be self-sufficient, i. e. to contain all parts > > that are required to build a working U-Boot image. I see a potential > > area of conflicts here. > > We don't have any problem including our SDK with U-Boot. I can work on trying But we probably will have problems adding tons of such code which is of no use to anybody else. > The biggest portions of our SDK are generated files for dealing with errors, > a register database (12MB!) and include files which define access functions > to I'd expect that only a tiny percentage of this is actually needed / used in U-Boot. We should restric it to these actually used parts. 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 "We don't have to protect the environment -- the Second Coming is at hand." - James Watt _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
