[U-Boot] Seperating MIPS processors

[Aaron Williams]

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