Re: [DISCUSSION] Hexagon code inside kernel

[Rob Landley <rob@landley.net>]

On 02/26/2013 01:32:40 PM, cotulla@yandex.ua wrote:
> 
> >  I think I've missed chunks of this conversation: what are you  
> booting
> >  it on?
> >
> >  (Wondering if I can get a test environment together. I haven't had  
> one
> >  since I left qualcomm in 2010.)
> >
> 
> Actually at the current time two persons are did some work in that  
> project:
> 0)Cotulla (me) - HTC HD2 (HTC LEO) QSD8250B QDSP6v2
> Image load done by custom MAGLDR bootloader.
> 
> 1)jonpry - HP TouchPad (APQ8060) QDSP6v3
> Image load done from kernel via PIL AFAIK.
> He also tried it on APQ8064 with QDSP6v4 but no luck with loading  
> unsigned LPASS images.
> 
> 
> Current kernel code located here in GIT:
> We took clear tree Linux 3.7.6 at the start and started to work with  
> it.
> https://github.com/detule/linux-hexagon

Cool. I haven't got hardware to do anything with it at the moment.  
(With the possible exception of my phone, but it's in use as a phone.  
Haven't even put cyanogenmod on it.)

> I am trying to bring up USB garget driver now.
> Already found that arm/mach-msm is also nosense. In common it's bad,  
> ugly code for something mythic.

If you poke Thomas Gleixner, he _might_ be able to help. (He did work  
under NDA, but some of the restrictions may have been relaxed when the  
code went upstream. If he can't help, he'll say so.)

You won't get a lot of time out of him, but he may be able to answer  
questions about where code lives in various public trees...

> I was trying to use a built in chipidea driver, but it looks  
> extremely overloaded and doesn't really fits for LEO hardware.
> I think I will try to port old msm7k_udc.c driver from 2.6.35. It's  
> much more simple.

I really want qemu support for this. Sigh. Are there public assembly  
docs anywhere? (I had a giant printout brick circa 2010 but remember  
almost nothing from it and gave it back when I left...)

> Also I found that adding "volatile" to variable declaration puts all  
> accesses to it
> as not grouped into packets.

What I _do_ remember is that each instruction is 32 bits, and that one  
of those bits is the grouping bit which is either on or off (I forget  
which) to indicate the end of a packet.

If you build -O0 it sets the bit on every instruction, _and_ I think  
feeds in NOPS to position instructions to go to the "right" cores when  
you need to do something the first or second core can't do. (I think #3  
and #4 are identical, but could easily be wrong.)

> So it can be easy workaround for uncached memory access problem,  
> instead of replacing
> everything to ioread32 and iowrite32.

Oh there's a CPU cache. The problem is the instruction dispatch is a  
fraction of the clock speed, and the clock speed's low to begin with  
(both to keep power consumption down). The speed comes entirely from  
parallelism, you really need to take advantage of that on this chip or  
performance is going to suck.

Rob--
To unsubscribe from this list: send the line "unsubscribe linux-hexagon" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html