[Arm-netbook] SATA - ATAS

[luke.leighton]

On Mon, Sep 9, 2013 at 1:08 PM, joem <joem at martindale-electric.co.uk> wrote:
>
>
>> > I got sunxi Linux compiling first time yesterday after getting
>> > the tool chains and set ups correct in Ubuntu 12.04.3 - but its not the
>> > EOMA one yet :(
>> > That is crashing left and right.
>
>>  what you *probably* mean is "the instructions for compiling sunxi
>> linux kernel aren't working for me"
>
> Nearly same problem - my environment isn't working for me.
>
>>
>> > From http://rhombus-tech.net/allwinner/a20/boot/
>> > When I run
>> >
>> > make -j3 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
>> > KDIR=~/src/a10/linux-sunxi/ -C arch/arm/mach-sun7i/pm/standby all
>>
>>  the KDIR environment variable is a standard linux kernel environment
>> variable, which says "my (K)ernal (DIR)ectory is ~/src/....".  so,
>> obviously, you have to adjust that for your setup.
>
>
> That is what got me confused - is the kernel sources sub directory not
> in the linux directory already?

 there *is* no quotes subdirectory - it *is* the kernel sources.

> If its not in there, what am I
> downloading when I do git clone http://git.hands.com/linux.git ?

 linux kernel sources.  there is only linux kernel sources.

>>  the -C option you can look up with "man make" - it says "after you've
>> loaded Makefile, change to directory arch/.... *before* starting
>> compiling".
>
> yup - though I have no idea why it needs to do that - which is what I
> want to understand and document.

 it's because allwinner can't fucking well get their act together and
play some stupid shit tricks rather than do a proper job where you
just need to run "make".

 so you have to do this stupid trick of separately-compiling up the
standby code.

 in the sunxi community code they've integrated the standby code
properly so you can just run "make".  however, in order to save time
i've started from the allwinner code, so it has the stupidity in it.

>
>> > Also, I noticed the script.fex has a lot of hardware enabled by default.
>> > Is that right Luke?
>>
>>  sort-of.  it doesn't really matter greatly.  but, it's a start not a final.
>>
>> > Just thinking out loud here - that script.fex
>> > needs to match the hardware that is wired out of the EOMA
>> > or it may to cripple the testing with tangential issues?
>>
>>  *hand-waving*... if you spot anything let me know.
>
>
> 100% hand-waving. I don't understand enough of the parameters in
> script.fex to make calls yet, but one thing I do know with ARMs is that
> if you do turn on and off features unnecessarily, they will trip each
> other up because pins are shared and you end up going off at a tangent
> with some driver issue, and then come back and say ooooopss!! (For
> example, in some Cortex CPUs I use, the ADC and GPIO should not be
> turned at the same time to the same pin or it will draw >300mA per pin
> that conflicts.)

 i'm reasonably confident there are not those kinds of mistakes in the
script.fex

> So for those with the know, I would say get the inventory of hardware
> bits in use and make script.fex best as can be. I was comparing
> script.fex with cubieboard2's and spotted the large number of
> differences where it appears more hardware has been turned on than off
> in the EOMA.

 i hacked it together from a random location - can't remember where i
got it, now.

l.