Jump to content

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


tkaiser

Recommended Posts

Armbian & Khadas are rewarding contributors

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

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 ?)

Link to comment
Share on other sites

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"  :)

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

 

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

Link to comment
Share on other sites

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)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

 

 

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 by tkaiser
Hide stupid fullquote again
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines