Quick review of LeMaker's Guitar

[Tido]

The LeMaker Team has released updates on its images v1601 (i.e. Lemuntu):

 

Release note:
> Update the display framework(HDMI as master device and LCD as slaver device by default)
> Add the HDMI-CEC driver
> Add the EDID analytic function on uboot

...

[Igor]

... and the broke the kernel sources somehow I was trying to build kernel two days ago but failed.

 

Now I noticed they are working on Linaro kernel.

[Tido]

I don't know about the Kernel, but it is still: Linux LeGuitar 3.10.37 #2 SMP PREEMPT Sat Jan 16 14:33:53 CST 2016

 

Until now, there was the issue that you only get 1024x600 resolution. I have tested this on my Plasma TV (HDMI-HDMI):

xrandr: Failed to get size of gamma for output default

Screen 0: minimum 1920 x 1080, current 1920 x 1080, maximum 1920 x 1080
default connected 1920x1080+0+0 0mm x 0mm
   1920x1080      0.00* 

The letters are not nice on the screen and changes in the settings of TV or OpenBox made no changes.

I don't know whether this is because a TV is never as good as a Monitor for PC ?

 

 

We have tested the newer display structure and have some bugs on the HDMI->DVI.

Although Peter wrote that, I gave it a try HDMI-DVI cable 19" Monitor with 1280x1024 = blank screen

This is sad, I guess many tinkerer have an old Monitor on their desk for things like the Guitar. I hope they fix this soon.

 

---

If I do xrandr on my Linux PC, that looks much better :-)

Screen 0: minimum 8 x 8, current 1920 x 1200, maximum 16384 x 16384
DVI-I-0 disconnected (normal left inverted right x axis y axis)
VGA-0 disconnected (normal left inverted right x axis y axis)
DVI-I-1 connected primary 1920x1200+0+0 (normal left inverted right x axis y axis) 518mm x 324mm
   1920x1200      60.0*+
   1920x1080      60.0                                                                                                          
   1680x1050      60.0                                                                                                          
   1600x1200      60.0                                                                                                          
   1280x1024      60.0                                                                                                          
   1280x960       60.0                                                                                                          
   1024x768       60.0                                                                                                          
   800x600        60.3                                                                                                          
   640x480        59.9                                                                                                          
HDMI-0 disconnected (normal left inverted right x axis y axis)  

[Tido]

Hi,

 

Maybe you didn't come across this posting, LeMaker has now updated the Kernel for the GUITAR.

 

 

@TK, this message is not for you   

[Igor]

I saw and build the kernel but could not boot it with my default / previous config. 

[tkaiser]

So they rebased their patch stuff for S500 on top of 3.10.94  (as we've told them since months), then added tons of fixes they got from Actions Semi the last few weeks, still patch a lot every few days and now it still breaks? Funny

 

Have you already looked whether the Roseapple Pi guys went the same route? I requested a board maybe half a year ago and now they sent one. While it's still far more interesting than the Guitar I won't touch it unless they cleaned up their sources and start to rebase their hardware support stuff based on 3.10.y like LeMaker tried.

[Igor]

I haven't look much into details but this might also be the result of their partnering with Linaro. They might be using Linaro's 3.10 LTS kernel with their patches to match Guitar HW. The kernel might also work with Roseapple too but not out of the box. I actually got their board few weeks ago. I boot their Debian image and Android which is on NAND to make sure HW is operational. 

In any case I need to dig in more to fix kernel and try to adopt it for Roseapple.

[tkaiser]

They might be using Linaro's 3.10 LTS kernel with their patches to match Guitar HW.

 

Yeah, seems so: Dec 10, 2015

 

Anyway I'm not interested in this Guitar misconception but in case things improve with Roseapple Pi please drop me a note to join in (we should unify things like IRQ distribution or at least make this less q&d and so on)

[Guest ThomasGB]

Question (I dont't want to make a new topic).

What do you think about Raspberry PI 3 ?

[tkaiser]

Raspberry 3? Pretty easy: It's the same SoC as on the 1st RPis from 4 years ago (max. 1 GB slow DDR2 DRAM, only one USB2.0 port to the outside) but now with Cortex-A53 cores you can't benefit from (at the moment) since the RPi foundation lets you run code that was written for ARMv6 on it.

 

We're currently discussing how to test dvfs/cpufreq settings for Pine64+ (concerned first about reliability and then about performance) and it seems obvious that not being able to use ARMv8 optimised code is bad. Same applies to slow I/O and network bandwidth (what is more important to my use cases) or for many average users the inability to decode HEVC video (works smoothly and HW accelerated on H3/A64 Allwinner SoCs).

 

For my use cases a RPi 3 is as useless as a LeMaker Guitar. YMMV as usual

[Tido]

Raspberry 3? Pretty easy: It's the same SoC as on the 1st RPis from 4 years ago

 

Such BS - did you mean SBC ?

 

Here is the table incl. SoC architecture

RPi was ARM11 v6 were as RPi 2 is v7 and the RPi 3 A53

 

Everybody knew, that Ubuntu doesn't run on RPi 1 because this architecture was not supported, but why does nowadays Ubuntu Mate run on RPi 2 ?

ARM v7

ARM v7 32-bit which is enough for 1GB RAM

USB2.0 = 480 Mbits / 8 = 60MB/sec  sufficient to support the 100 Mbits ethernet port, as long as I/O is not an issue.

 

This is a tinkerer device, not a multimedia System, not a NAS or anything else with high load.

[tkaiser]

Such BS - did you mean SBC ?

 

I meant what I wrote: SoC. It's basically the same crappy SoC than on the first SBC they sold, the only thing that changed are count and type of the contained ARM cores. Why should I comment on the weird sentences that followed your question? You do not even understand 8b10b, confuse Mbps with Mbits/sec, think that a specific ARM generation dictates maximum RAM (it's the VideoCore GPU/VPU that is not able to initialise more than 1 GB) and so on...

 

Let's see whether the RPi's boot process (again: VideoCore brings up the hardware and initialises everything) ever will be able to bring up the Cortex-A53 cores in Aarch64 state on the RPi 3.

[Tido]

I meant what I wrote: SoC. It's basically the same crappy SoC than on the first SBC they sold

to repeat wrong information does not make it correct.

 

There are two questionmarks written by me, one you answered, the other I answered by my self, "this is quite obviously".

 

 

WTF, should I care about 8b10b - does it change the number by factor 10? If not I give a BS about it I just want to have +- figure in MB.

(symbol Mbit/s or Mb/s, often abbreviated "Mbps") the / is missing I give you that, but based on the calculation you should actually understand it anyway.

 

 

 

a specific ARM generation dictates maximum RAM (it's the VideoCore GPU/VPU that is not able to initialise more than 1 GB)

 

Again wrong. What I was refering to is the fact that with 32-Bit you can easily address RAM upto 3 or 4 GB, no need for 64-bit.

 

If you had listen to the podcast I recommended you - you already knew that it is not their intention to do so (more than1GB & Aarch64).

[Guest ThomasGB]

O.K.

you gave me the most information. My opinion ist: An 64Bit processor fitted with 1 GB is as usable as 32 Bit with 560 MBit.

And it make more heat and more problems. My impilcite question to the IO i(and USB) is answered by you too. The whole tihng would be (perhaps) interesting with an USB3-Port. But that's not fact ...

Zusammengefaßt: Uninteressant. Thank you for your answer !

[tkaiser]

An 64Bit processor fitted with 1 GB is as usable as 32 Bit with 560 MBit. And it make more heat and more problems.

 

Both not entirely true. The SoC used on the RPi 3 is a ARMv8 Cortex-A53 implementing both Aarch64/Aarch32 so it might be an interesting hardware to test out how ARMv8 optimised code performs better and how this 32-bit vs. 64-bit thing behaves.

 

For example: we're currently playing with a high performance benchmark called Linpack on Pine64. Why? Not because we want to provide benchmark scores but since Linpack is able to detect data corruption due to undervoltage (something I torture my 2 Pine64 with at the moment): https://github.com/longsleep/build-pine64-image/pull/3#issuecomment-195928362

 

Another benchmark that we wanted to use for reliability testing -- cpuminer -- isn't that demanding (produces less heat and doesn't verify its own results) so we dropped it. But it's interesting to compare how way more performant code for ARMv8 is compared to ARMv7. Quoting myself:

 

 

 

BTW: I let cpuminer and Linpack also run on Orange Pi PC (H3, 1296MHz): 2.35 khash/s and 1.73 Gflops on H3 vs. 3.9 khash/s and 3.4Gflops with A64 running at the same clockspeed.

 

And the RPi 3 also gets 3.4 Gflops but data corruption occurs (most likely due to undervoltage in combination with overheating -- if you're interested in this then check the links in the aforementioned thread/issue).

 

Then overheating isn't a 64-bit phenomenon but that's simply a problem nearly all modern SoC show and it's a matter of improved heat dissipation (hardware: enclosure design, good heatsink and for constant high performance an annoying fan on top) and throttling strategies (software) how to deal with that. An A83T (octa core Cortex-A7) or S500 (quad core Cortex-A7) show also heat problems. Interestingly the H3 that has been blamed last year for overheating does not that much when driven with sane settings (like Armbian does -- it's just a matter of sane throttling settings and the chip stays both cooler and performs faster)

 

And the last thing: This whole "how much DRAM?" thing. With a 64-bit architecture you have a huge virtual address space already that might make a difference regardless of the amount of available physical DRAM. Most if not all cheap 64-bit SoCs do not support more than 2/3/4 GB physical RAM anyway so the magical '4 GB barrier' doesn't play any role at all. But it might make a difference if you use a 64-bit SoC that can only deal with 1 GB slow DDR2 or one that can use 4 GB DDR4 if your use case is really memory dependant (the aforementioned Linpack with the settings I used isn't able to run on systems with less than 1GB).

 

For me the two most important things regarding RPi 3 are

• It's uninteresting from a developer's point of view (proprietary boot procedure)
• It's uninteresting from a user's point of view (less I/O and network bandwidth)

The one and only interesting thing for me with RPi is the ability to get there working HW accelerated video encoding. But since this happens on the VPU every RPi A/B performs identical to RPi 2/3 (that's what I meant with: It's the very same SoC as before just with exchanged ARM cores).

 

BTW: If you're interested in SBC comparisons then reading blogs like CNX (and especially the comments there) is a way better source than here, eg.: http://www.cnx-software.com/2016/03/01/raspberry-pi-3-odroid-c2-and-pine-a64-development-boards-comparison/#comments

[Guest Guest]

Thats the point I mentioned,

 

"It's uninteresting from a user's point of view (less I/O and network bandwidth)"

 

I have an USB-Camera combined with Raspberry, BananaPIM2, Orange PI and Odroid C1+.

The Problems are alway the same.

- The most time I loose is while transfering picture-data. (~90%).

- Raspberry has problem with the data-rate on USB. That means: From some some point the connection breaks, recover is only possible by restart. All the other don't have such "Fissimatenten".

- Raspberry is very sensible about heat. From 51,8C it becomes problems. Sometimes more, sometimes less....

- One BIG problem with the other systems is the missing GPU support. Nixda mit "ice, ice baby" ...

What you told about Orange PC is right. It could be a better Raspberry.

 

So, und der Rest auf Deutsch: Momentan ist - so absurd das klingt - der BananaPI M2 immer noch das stabilste. Den kann man im Prinzip mit einem Schweißbrenner bearbeiten - das Ding gibt nicht auf.

Sehr gut ist auch der neue Odroid C1+. Allerdings ist das Betriebssystem sowas von veraltet, daß es sich eher wie ein Mädchen in der Pubertät benimmt. Da muß man mit Samthandschuhen dran herumtätschel, sonst verzieht er sich in sein Zimmer schließt die Tür zu und heult herum ...

Beim OrangePI PC, naja. Ich habe früher auch Systemprogrammierung gemacht. Auf OS9 (Microware). Das ist ähnlich wie Linux. Ich habe schon mit dem Gedanken gespielt zu sagen: Ihr bringt den Video-Bereich zum laufen und ich kümmer mich um die Mali-Geschichte. Aber ich bin mit 50 Jahren zu alt dazu. Ich haben dazu nicht mehr den "drive".

Aber interessant ist das Teil in der Tat, da hast Du recht ...

 

Liebe Grüße

Thomas

[Tido]

The LeMaker Team has released an update on its image v1604 Lemuntu:

 

Release note:

Kernel 3.10.94

Rootfs upgrade to Debian Jessie 8.4

...