problems recently compiling linux kernel with usual hno sources

Guillaume/Jeff/Gnexus etc


are you having problems compiling the kernel using the usual https://github.com/hno/linux-allwinner.git - allwinner 3 android v2

I'm now getting the error message every time :

arch/arm/kernel/head.S:93:2: error: #error "unsupport chip"
make[1]: *** [arch/arm/kernel/head.o] Error 1
make: *** [arch/arm/kernel] Error 2

I know a lot of changes for "cubieboard" have been entering lots of sources recently and wondered if support for the mele has been overwritten out ?

whats the best source now for a kernel compilation for the mele (to do a debian arm hf headless build) pref incorporating sata patch (or that there is a patch that can patch this source)


thx

ian

Hello,

I have documented what i have done to get the same config (headless, armhf, full memory) here:

http://guillaumeplayground.net/allwinner-a10-cluster-mele-a2000/

I used the vanilla amery tree as you know and you can apply any of the sata patch available in issue 40 (and the last one from the ML also working - the last one is what i have rework from the cubie team patch).
Issue 40: https://github.com/amery/linux-allwinner/issues/40
ML: https://groups.google.com/forum/#!topic/linux-sunxi/eu3xw-nsxoM/discussion

Quote

I know a lot of changes for "cubieboard" have been entering lots of sources recently and wondered if support for the mele has been overwritten out ?

As far as i know, only the 60 cubieboard sold by Tom via aliexpress have been produced... Am i wrong?

Guillaume,

hi

ive been x-compiling different kernels for a good few months with no problem until the last couple of weeks and all of a sudden i get this error message (which is quite strange), As i'm doing it all in a linux vm .. i might just install a new linux vm and see if that helps if you have seen no issues recently just in case i've crapped up the distro

thanks for your sterling efforts in getting the SATA sorted out, particularly in going about it in such a professional way . thats hopefully one of the last bits to getting this melebox replacing my old hacked iconnect and doing something useful

I.R.O cubieboard I.M.H.O. its not going to sell that many, the raspi with its fantastic professional support and friendly usercommunity will kneecap it at the bottom end ( p.s. Sony factory in the UK are now building a batch of 300k pi's) and at he top end we are already seeing quad core CPU with a decent linux build < $150 and hopefully with the Freescale imx6 (if it arrives as promised in Nov) giving circa cubie board price single and dual core boards with a decent linux and drivers

it looks as though a lot of the activity on the GIT A10 linux is directed at cubieboard which is a pain if the mele is going to be passed by .. probably the reason why the SATA fix isnt incorporated in the hno mainstream A10 linux but its in the hno cubieboard stream

best rgds

ian

Quote

are you having problems compiling the kernel using the usual https://github.com/hno/linux-allwinner.git

I've never used hno's kernel. It's certainly not "the usual."

hi,

yep .. i must have crapped up the VM , reinstalled ubuntu VM this time and it's fine now :

i thought the GIT source most people were currently using was from :

git://github.com/amery/linux-allwinner.git

and the android v3 android 2 branch

whats the best out these at the moment if this isnt what ppl are using ?


Guillaume, hi .. do you have the patched files (im sure they will be same whatever the branch) for the SATA fix and the wemac fix ... i was struggling to get your patch on the cubie forum to patch the clock.c on this branch of the git source

Hi,

It was commited to the amery tree yesterday ;-)
You can checkout it directly.

For the wemac, seems a bit experimental and the biggest part is integrated in amery tree (delay changes, etc..)

Seems fine to use amery directly (wemac and sata fix)

allwinner-v3.0-android-v2 branch

Regards,
--
Guillaume

Guillaume,

hi


excellent & thanks .. thats what i'd used to compile the kernel i'm using but i wasnt sure from the cubie forum post if the amery tree had used the cubie patch (with your comments on the risk of using it) or a new iteration

Running on a headless Wheezy build I'm getting (with HD parm) with a 640MB WD blue 2.5 5400rpm the following throughput which seems low - do you think its low based on what youre seeing and if so perhaps it's the kernel config settings ive used for sata/scsi ? any sugggestions to improve things ?

hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads: 74 MB in 2.03 seconds = 36.38 MB/sec
Timing buffered disk reads: 56 MB in 3.01 seconds = 18.63 MB/sec

In terms of the kernel config Ive selected the softwinner sata driver & disabled the other sata driver option and left the rest of the sata and scsi settings as in the default defconfig .. (the default defconfig had the softwinner sata driver disabled and the generic sata driver enabled) .. i found i had to enable the softwinner driver to get sata working


HDParm reports :

Model=SAMSUNG HM641JI, FwRev=2AJ10001, SerialNo=S23TJ1ZZ300363
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1250263728
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: unknown: ATA/ATAPI-0,1,2,3,4,5,6,7

* signifies the current active mode


thx

ian

Here are mine with sub $60 SSD 64Go drives.. vanilla config.

Model=OCZ-AGILITY3, FwRev=2.22, SerialNo=OCZ-C1BH5X9TKRURQ032
/dev/sda:
Timing cached reads: 666 MB in 2.00 seconds = 332.54 MB/sec
Timing buffered disk reads: 306 MB in 3.02 seconds = 101.43 MB/sec

Model=KINGSTON SVP200S37A60G, FwRev=502ABBF0, SerialNo=50026B722802BC70
/dev/sda:
Timing cached reads: 606 MB in 2.00 seconds = 302.59 MB/sec
Timing buffered disk reads: 306 MB in 3.01 seconds = 101.77 MB/sec

Model=M4-CT064M4SSD2, FwRev=000F, SerialNo=000000001145031EC326
/dev/sda:
Timing cached reads: 618 MB in 2.00 seconds = 308.39 MB/sec
Timing buffered disk reads: 322 MB in 3.01 seconds = 107.01 MB/sec


Far enough to saturate the wemac ;) and at the price of a classic hard-drive.

Seems to me the current wemac is buggy in Amery tree. I didn't had time yet to investigate but i was getting a huge amount of connections failure so i rolled back to my previous tuned version.
They have desactivate the PHY_POWER. Don't know why. And seems to have some delay/msleep badly modified.

i'm jealous :-) ... did u use the softwinner SATA driver in the kernel config (it was deactivated by default) and deactivate the generic sata driver

or vice versa

or leave both activated ?

seems to me i should be getting much more out of the sata drive than i'm getting ?

thx

ian

Hi,

I'm using the vanilla sw_ahci_platform. Drives are showing up in sata2, 3Gbps.
I just think the WD blue 2.5 5400rpm is slow and the mele sata is fine.

For the same price as a Crucial m4 or other, you just get a x10 bigger storage and x10 slower device. Your choice ;)

regards,
Guillaume.

no choice at the time v.large.media collection and GBP40 for a 640GB drive

I ran it again a few times because our hdparm T nos should be similar (and mine were vastly lower) but weirdly now when i run the same hdparm -Tt /dev/sda

i get

/dev/sda:
Timing cached reads: 604 MB in 2.00 seconds = 302.00 MB/sec
Timing buffered disk reads: 246 MB in 3.01 seconds = 81.74 MB/sec
(the former is pretty constant around 300MB/s .. the later more often than not around 38Mb/s)

I'd be happier around 60MB/s but hey c'est la vie

How wierd is that .. must have had a love in with softwinner sata ;-)

As i understand it the former (T) is a measure of cpu/mem (not disk) throughput and the latter (t) a measure of disk throughput and perhaps when i was running it the first time the mele was up to no good elsewhere with its processes ;-)

with ext usb2 likely around 25MB/s .. at least my softwinner SATA is beating that now ;-)