On 02/12/2011 08:29 AM, Daniel Schwierzeck wrote: > Hi, > > On 02/12/2011 07:19 AM, Aaron Williams wrote: >> Hi, >> >> One thing that I have had to do in our Octeon port of U-Boot is to >> seperate >> out the MIPS processors under /arch/mips/cpu much like has been done >> for ARM >> and PowerPC. > > I'd appreciate this separation as it would help me too in supporting > new Mips-based SoC's. > >> >> I have no way of testing the other MIPS platforms, but I've seperated >> things >> out as follows: >> >> arch/mips/cpu/au1x00 >> arch/mips/cpu/incaip >> arch/mips/cpu/mips32 >> arch/mips/cpu/octeon >> arch/mips/cpu/purple >> >> All of the code that's common between various 32-bit mips processors >> I put >> under mips32 with only the processor specific files in the appropriate >> directories. Is this how I should do it? > > Actually all existing CPU's are SoC's based on a Mips4k core. So I > think a better approach that fits into the common u-boot configuration > scheme is to have a structure like this: > > arch/mips/cpu/mips4k/au1x00 > arch/mips/cpu/mips4k/incaip > arch/mips/cpu/mips4k/purple > arch/mips/cpu/mips24k/... > arch/mips/cpu/mips34k/... > arch/mips/cpu/mips74k/... > arch/mips/cpu/octeon > > The according lines in boards.cfg could be changed from: > > dbau1000 mips mips dbau1x00 - - dbau1x00:DBAU1000 > incaip_100MHz mips mips incaip - - incaip:CPU_CLOCK_RATE=100000000 > purple mips mips - - - > > to: > > dbau1000 mips mips4k dbau1x00 - au1x00 dbau1x00:... > incaip_100MHz mips mips4k incaip - incaip incaip:... > purple mips mips4k - - purple > This looks reasonable to me. We have so little in common with the other MIPS platforms to where even lib/board.c is unusable for us. The only parts we share are some of the include files, and even there we have to make a lot of extensions for 64-bit support.
>> >> Right now I can't really use any of the other MIPS files for our Octeon >> processor. There's just too many differences for this to make sense. >> >> I basically have the following directory structure: >> > ... >> >> While it might be quite a while until I can get our stuff into the >> mainline, >> it would certainly make things easier for me not to have to place our >> stuff in >> the same directory as the other processors. >> >> -Aaron > > I agree. Generally Mips lags behind the other archs in terms of some > features or config options because of the little support of boards and > SoC's. Introducing new CPU's like Octeon should give reason to improve > some parts. > > Daniel I hope one day to get our stuff into the mainline u-boot tree since we are implementing quite a bit. So far I'm able to take advantage of just about everything U-Boot has to offer with our SOC, but the biggest problem remains the drivers due to some bad assumptions people make that there's no difference between a pointer and a physical address. It's even worse for us since all of our hardware is mapped above 4GB in 64-bit address space plus due to other requirements we use TLB mapping to map U-Boot to the top of physical memory (which is often above 4GB). Taking advantage of a 64-bit processor presents a lot of challenges for U-Boot. A lot of our changes apply to 64-bit MIPS in general though we also have a lot of specialized stuff for dealing with our SDK environment (currently 16 cores, soon 32 cores). Hopefully I can further expand MIPS support. I'd love to get kgdb support working since this would be a big boon to our customers since we support loading SDK applications on different cores independent of operating systems (we also support multiple instances of Linux running on different cores). The biggest problem I see is that the toolchain we use is not publically available. I might try doing what we did for the Linux kernel to create a stripped-down SDK and get it working with the Debian toolchain. -Aaron _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
