Armbian running on Pine64 (and other A64/H5 devices)

[tkaiser]

No idea, boot0 is a blob anyway, and I'm not sure open-source SPL can be easily changed without having something that already works to dump the DRAM controller registers

 

I'm stupid and sent you to the wrong location. Fortunately I sometimes remember what I write here and there

 

http://linux-sunxi.org/Pine64#Variants

[zador.blood.stained]

I'm stupid and sent you to the wrong location. Fortunately I sometimes remember what I write here and there

 

http://linux-sunxi.org/Pine64#Variants

Yeah, that one works... except that mainline SPL would have been better 

[tkaiser]

mainline SPL would have been better 

 

True. Given how 'innovative' Allwinner is maybe we could take the bits Vishnu added to mainline u-boot for BPi M3 (also 2GB LPDDR3) for SoPine too?

[zador.blood.stained]

True. Given how 'innovative' Allwinner is maybe we could take the bits Vishnu added to mainline u-boot for BPi M3 (also 2GB LPDDR3) for SoPine too?

Actually I compared boot0 blobs for normal Pine64 and for SO one and differences are minimal. I'll try to compare register dumps later too if I can make the main u-boot binary work

[umiddelb]

I've built the kernel once again using the Armbian build chain on my x86_64. The good thing is, the result is exactly the same. The bad thing is I still have no working USB ... will look into the differences of the shipped defconfig compared to mine.   

[umiddelb]

I've found the difference, the kernel shipped with the Image is version 4.9.0 and not 4.10-next. I'll go back up to commit cb9ee352f26dbd8ec90e683442a53f0076e762e3.

[umiddelb]

OK, I've added the missing kernel parameters (by merging the config-4.9.0-pine64 shipped with the Armbian install image) and built a 4.9 kernel with USB and Docker support. You can find the defconfig here.

Is there a reason why the linux-pine64-dev.config cannot be found here?

[zador.blood.stained]

OK, I've added the missing kernel parameters (by merging the config-4.9.0-pine64 shipped with the Armbian install image) and built a 4.9 kernel with USB and Docker support. You can find the defconfig here.

Is there a reason why the linux-pine64-dev.config cannot be found here?

Because it is called linux-sun50i-dev.config (it is shared with Orange Pi PC2)

[umiddelb]

Thank you! The latest revision of linux-image-dev-pine64 (5.25) is absolutely fine. Sorry for the noise.

[martinayotte]

I found a strange bug and seen it twice in a week :

 

After few days running, my PineA64 had wrong date, some thing like "Tue Mar 13 20:50:11 EDT 2153".

Trying to restart NTP didn't fix it. Trying to set it manually give me an error :

root@pine64:~# date -s "2017-02-03 00:00:01"
date: cannot set date: Invalid argument

Doing an "strace" with it reveal that it can not write system clock :

settimeofday({1486098000, 0}, NULL)     = -1 EINVAL (Invalid argument)
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3

Doing search on the net, I've found http://nerdbynature.de/s9y/2009/07/22/cannot-set-date-Invalid-argumentand http://www.mail-archive.com/bug-coreutils@gnu.org/msg14103.html, but not real answers other than it is really the kernel that are f*k*ing up with the system clock. And the issue is gone if I simply reboot the board. Really strange ... Especially that it happened only on PineA64 ...

 

As someone got the similar issue ?

[zador.blood.stained]

Is there support for the hardware RTC in mainline (assuming you are testing the mainline)? If yes, then it may be related to wrong RTC settings like external or internal oscillator. If not - then maybe it's related to the arch timer bug? https://github.com/longsleep/linux-pine64/issues/44#issuecomment-263060276
 

Doing an "strace" with it reveal that it can not write system clock :

settimeofday({1486098000, 0}, NULL)     = -1 EINVAL (Invalid argument)

I think kernel just prevents unsafe date/time changes, there are several -EINVAL returns in the date/time changing code.

[martinayotte]

I was just looking at DT about this, because if I remember, I didn't had the issue up until recently.

I'm seeing that in the old longsleep DT, it was using 'sun50i-rtc' and in the current it is using 'sun6i-a31-rtc'.

Since I kept also several A64 armbian previous images, I will look into them too.

(I will also check what is the frequency of the occurence, because maybe it happen every 24hrs by reading wrong value from a sync service call. Let see tomorrow ...)

(Another thing I found : the H3 has /dev/rtc and clear trace in dmesg, but not with H5 or A64, no trace at all. But why I don't have the same issue with H5 ?)

[martinayotte]

To avoid further lengthy discussion about this A64 date/time clock issue, I've created new thread here : https://forum.armbian.com/index.php/topic/3458-a64-datetime-clock-issue/#entry24814

[zador.blood.stained]

OK, I made hacky and somewhat working A64 LPDDR3 support, so I can boot mainline u-boot+kernel on SoPine. Next step is figuring out MMC issues...

[martinayotte]

Oh ! you received a SoPine ? Lucky guy !

[zador.blood.stained]

Oh ! you received a SoPine ? Lucky guy !

• LPDDR3 support is hacky and experimental (and even worse - made by me from memory dumps and A83T/Banana Pi M3 code)
• now looks like MMC has different card detect polarity or something worse
• Also since the SoM is small and there is not heat transfer to the baseboard the SoC easily heats up to 85-90°C w/o a heatsink on legacy kernel and performance governor

So even though it has improvements over the old Pine64 like eMMC slot, SPI flash, proper power supply connector (though 3.5mm barrel plug and not 4.0 like on Oranges and Cubietruck), it still needs work to be done to consider myself "lucky" 

[tkaiser]

Also since the SoM is small and there is not heat transfer to the baseboard the SoC easily heats up to 85-90°C w/o a heatsink on legacy kernel and performance governor

 

Just curious: what's your strategy to deal with this running mainline kernel now (BTW: Kudos! You got it working!)? Sounds like having 'safety headroom' in mind we must limit clockspeed to 480 MHz as long as there's no working throttling? Did you test how lot cpufreq goes with legacy when running cpuburn-a53?

[zador.blood.stained]

Just curious: what's your strategy to deal with this running mainline kernel now (BTW: Kudos! You got it working!)?

My strategy - put a heatsink on it and trying not to accidentally burn the fingers 

 

Sounds like having 'safety headroom' in mind we must limit clockspeed to 480 MHz as long as there's no working throttling?

As long as there is working DVFS or at least DFS we should think about it, and I have some other concerns in mind too.

 

Did you test how lot cpufreq goes with legacy when running cpuburn-a53?

For me it went to 80+°C in idle (and performance governor), I'm not sure I should attempt cpuburn with our settings from the "big" Pine64 without active cooling or at least a normal heatsink and not a stack of coins that I'm using now.

[tkaiser]

For me it went to 80+°C in idle (and performance governor)

 

Wow, that's an awful lot.

 

TL Lim talked about a 'Graphene nano technology heatsink' (sent you an email regarding this just now) but obviously you didn't get one? They also wanted to explore other heatsink options and based on your observations it seems that's mandatory to do anything with SoPine at least if it's about the use cases this module has been designed for in the first place.

[zador.blood.stained]

TL Lim talked about a 'Graphene nano technology heatsink' (sent you an email regarding this just now) but obviously you didn't get one?

No, only SoPine, baseboard (with no eMMC) and a 5V/3A power supply with US type plug 

 

They also wanted to explore other heatsink options and based on your observations it seems that's mandatory to do anything with SoPine at least if it's about the use cases this module has been designed for in the first place.

Well, these temperatures are not a surprise given the SoM board size and type of CPU cores. It should be fine with an adequate heatsink or any kind of other thermal interface.

[Xalius]

I also have one of the new SOPine now (with eMMC port and SPI Flash) and trying to come up with a 3D printable heat sink spacer that mechanically supports the SO module and allows clip-on mounting of some standard heatsink with thermal pads...

 

If someone needs a SOPine for development purposes please tell me, I can probably forward requests to Tl...

 

I also got a prototype 11inch Pinebook from Tl during the linux-sunxi meeting at FOSDEM, I will try to make an Armbian build target for it once ayufan and me figured out all the bits to have proper u-boot and a patches for longsleep's BSP kernel. Currently ayufan has boot-tools on his github using FEL to expose the eMMC on Pine or Pinebook as USB mass storage which makes writing images a lot easier.

[tkaiser]

Currently ayufan has boot-tools on his github using FEL to expose the eMMC on Pine or Pinebook as USB mass storage which makes writing images a lot easier.

 

I've seen this already and wonder how fast writes are? Based on tests with other Allwinner SoCs it seems u-boot currently provides pretty low sequential write speeds in this mode. After some discussions Mikhail came up with a similar approach half a year ago (using sun8i legacy kernel's USB mass storage gadget mode which provides ~20 MB/s write speeds IIRC): https://github.com/zador-blood-stained/fel-mass-storage (would be great if other SoCs could be added there too)

 

Regarding the eMMC connector on SoPine's baseboard: looks similar to the ones Hardkernel uses on some ODROIDs. Do you have any information (to share) on this?

 

BTW: Since I sent Mikhail the wrong boot0 blob for SoPine in the beginning (not useable with LPDDR3) I would believe Pinebook also uses DDR3(L) now? Can you or Kamil confirm?

[Xalius]

 

I've seen this already and wonder how fast writes are? Based on tests with other Allwinner SoCs it seems u-boot currently provides pretty low sequential write speeds in this mode. After some discussions Mikhail came up with a similar approach half a year ago (using sun8i legacy kernel's USB mass storage gadget mode which provides ~20 MB/s write speeds IIRC): https://github.com/zador-blood-stained/fel-mass-storage (would be great if other SoCs could be added there too)

 

Regarding the eMMC connector on SoPine's baseboard: looks similar to the ones Hardkernel uses on some ODROIDs. Do you have any information (to share) on this?

 

BTW: Since I sent Mikhail the wrong boot0 blob for SoPine in the beginning (not useable with LPDDR3) I would believe Pinebook also uses DDR3(L) now? Can you or Kamil confirm?

 

 

I did write some images to the internal Pinbeook eMMC yesterday and got speed between 50-60MB/s , reading was around 80MB/s as reported by dd but that seems a little high for USB2.0... ayufan did some measurements too https://gist.github.com/ayufan/caf1a581a53e3d16772ee363f7f5b075

 

I think Tl said the pinout is compatible to the hardkernel modules, but I can verify that with the schematics maybe...

 

As far as I know (from the schematics and looking at the boot output of the stock AW Android images) it is LPDDR3 ... I should probably start a wiki entry on linux-sunxi...

 

Pinebook schematic seems to be on the shop page now: http://files.pine64.org/doc/pinebook/pinebook_mainboard_schematic_1.0.pdf

[tkaiser]

I did write some images to the internal Pinbeook eMMC yesterday and got speed between 50-60MB/s , reading was around 80MB/s as reported by dd but that seems a little high for USB2.0... ayufan did some measurements too https://gist.github.com/ayufan/caf1a581a53e3d16772ee363f7f5b075

 

I came already across his iozone test and linked to it on CNX. And 80MB/s through USB2.0 is not just a 'little high' but simply impossible (the best you could get with UASP which isn't implemented by u-boot on a single connection is 41 or maybe 42 MB/s).

 

Regarding LPDDR3 vs. DDR3 please see post #237 and #238 of this thread. I wonder why the specific boot0 blob works for ayufan. Anyway: would be great if you can try to clarify this and correct my sentence here if it's LPDDR3: http://linux-sunxi.org/Pine64#Variants (just added link to schematic a minute ago)

[zador.blood.stained]

I think Tl said the pinout is compatible to the hardkernel modules, but I can verify that with the schematics maybe...

At least mechanically the connector is compatible with eMMC for Odroid C2, but I can't find the eMMC slot on the SoPine schematics.

[Xalius]

I just took a closer look at my Pinebook PCB and the DRAM chips are https://www.micron.com/parts/dram/ddr3-sdram/mt41k256m16ha-125-m x 4

 

1.35V DDR3L-RS SDRAM with D9QLJ stamp code

 

256 Meg x 16 256M16

 

96-ball 9mm x 14mm FBGA

 

tCK = 1.25ns, CL = 11

 

1600 11-11-11 13.75 13.75 13.75

 

This PCB is a V1.1 Version from september 2016, so they could have changed DRAM for the next version as the schematic states... 2017-01-10 on page 4 for the DRAM

[hojnikb]

 

 

I just took a closer look at my Pinebook PCB and the DRAM chips are https://www.micron.com/parts/dram/ddr3-sdram/mt41k256m16ha-125-m x 4

 

1.35V DDR3L-RS SDRAM with D9QLJ stamp code

 

256 Meg x 16 256M16

 

96-ball 9mm x 14mm FBGA

 

tCK = 1.25ns, CL = 11

 

1600 11-11-11 13.75 13.75 13.75

 

This PCB is a V1.1 Version, so they could have changed DRAM for the V2.0 as the schematic states...

 

 

Where did you get your pinebook ???

 

edit: nevermind, i see you got a prototype... Can you write more about it (quality, battery ,screen etc) ?

Edited February 11, 2017 by tkaiser
Hide stupid fullquote again

[Xalius]

I just talked to ayufan and he confirmed that current prototypes use DDR3L and the upcoming new PCBs use LPDDR3, so boot0 / dts will be slightly different

[hojnikb]

Can you say, when those are gonna be available for purchase ?

[Xalius]

I don't work for Pine64, but last thing I heard was that they are checking out production schedules now that Chinese New Year is over, I guess that means production could start around end of february?