PINE64

(09-21-2016, 12:55 AM)tkaiser Wrote: [ -> ][This is] what Etcher is about. The tool's development has been driven by another community that suffers from the very same problems this community has. And what happens here? Nothing, still the same recommendations that waste time on user's and supporter's side since broken burning processes aren't ruled out. It's just insane to recommend this Win32 thingie these days (was great years ago but isn't any more)

I agree whole-heartedly.  Its time to switch recommendation at least as it pertains to defaults and to the windows users out there. Of course there is nothing wrong with dd , and it is easily verified too , but Etcher is running on every platform ( particularly useful for windows users ) and as a default system for linux and mac also a great option. The verification process is good, and the track record of this open source utility is also quite good.  I agree that the support community here needs to drop the recommend for win32diskimager immediately ; there are just too many folks having corrupted SD card issues-- its getting to be ridiculous actually. Let's try to get a concensus, and make some positive changes here.

This is the download page for "Etcher" :

https://www.etcher.io/

 Their page says, after you download the linux version, to modify the attributes to be executable, by the command:

chmod a+x Etcher-linux-x64.AppImage

(Of course you can also do this the GUI way, like I did, through the Ubuntu file manager.)

The program would then be run from the command line. (but I personally double clicked the file in the file manager.)

Their page has this notice: AppImages require FUSE to run

As far as I know, FUSE has been part of a standard Ubuntu desktop install for quite a while. (FUSE is one way of auto-magically mounting and un-mounting disk drives, I believe.)

"Etcher" is not in the Ubuntu repositories, and no deb file is planned from the company. The massive 67 megabyte package is supposed to be written in java script, but with tons of specialized packages, as you would expect. (dd is 0.08 megabytes)

Etcher works nicely, is about as straightforward as programs get, and it wrote the armbian Xenial image (2G) to microSD about as quickly as anything (< 2 minutes.) The checking stage took maybe 30 seconds. I am taking their word that this is a valid 100% read check.

As a matter of information, .img files have been around a long while to be used by linux backup and restore programs, so you can "restore" these image files with these kinds of programs, even though you haven't backed them up yourself. I already have the very visual, but maybe too clever, "gnome-disks" program for other profuse functions (SMART on-drive tests, benchmarks, renaming partitions), which also can create and restore images, when you click on the rather clever places to bring up menu's. Maybe it does too much, or is rather too clever, to avoid causing confusion. But you don't have to know any command parameters. Installing programs from the standard repos automatically puts the execution attribute on.

To install:
sudo apt-get install gnome-disk-utility

As a matter of fact installing Ubuntu for desktop has also installed this utility for years. However, on the menu it is just called "Disks", and I doubt if people would guess what it does. But the program itself is named "gnome-disk". It once was called "palimpsest."

(09-21-2016, 05:02 PM)kflorek46 Wrote: [ -> ]Etcher works nicely, is about as straightforward as programs get, and it wrote the armbian Xenial image (2G) to microSD about as quickly as anything (< 2 minutes.) The checking stage took maybe 30 seconds. I am taking their word that this is a valid 100% read check.

Etcher is horribly bloated. That's what you get when you start deploying real applications made with scripting languages. I came accross it just recently since I thought for myself: Let's write a tool for OS X that helps Armbian users burning and verifying our images. Made a list of features, did a web search for this, discovered Etcher, tested Etcher, dropped the idea to reinvent the wheel even if the Applications I'm able to create with my toolchain are usually less than 1 MB in size (and Etcher on OS X wastes +200 MB).

If you're on Linux and know what you're doing, know about SD cards, know how and why to verify your burn process... you don't need other tools than dd and cmp/md5sum (same applies to every other OS, even in Windows you can verify with winmerge or whatever tools).

The average Pine64 user is not an expert in these things (and should not be one!) and can not even imagine that he can buy counterfeit SD cards directly from Amazon, that his new SD reader starts to corrupt writes to cards after ~1 min due to overheating, that his USB front ports are prone to EMI and he constantly fails writing images using the front ports while the USB back ports would work and so on.

On Pine64 OS images also have no way to tell whether they work or not (there is not a single custom led on Pine64/Pine64+ we could use to give user feedback like 'it boots' by blinking or solid light and so on).

Users when fed with misleading instructions (that's one of the worst problems around Pine64) also get creative. They're told to use 'SD Formatter' somewhere in the forums, format their card (which is absolutely useless), copy the compressed ISO image (the .zip file) on it and try to boot. Will never work.

Most people don't like to be told 'you probably did something wrong' since it gets annoying pretty fast. But unfortunately there are a lot of possibilities to 'do something wrong' and some are not related to the user at all (a bad SD card is a bad SD card and you get those from the most trustworthy sellers since they can't prevent selling counterfeit cards as they're injected into the supply chain pretty early)

All this is long known so why not simply recommending a tool that is able to stop this mess? Even if it's somewhat bloated. Etcher's killer features are the result of a different approach (and that's what it makes really special): it is software written with the user and the task to accomplish in mind. They thought first 'what's the problem?', 'what's the steps people are failing with' and then started to code. It's an active project and listens to suggestions. If people would just start to use it...

Let's start to propagate a tool that helps those users that need some help in this stage the most (Linux experts will use their own tools anyway)

Back to the topic at hand ..... any updates on the GbE issue ?

Tllim, anyone ; could you update us on progress anywhere ?
1 Patch from olimex to do some magic with the autoneg
2 Possible Powerpath issue
3 Possible takeback of impacted boards

Meanwhile olimex seems to have dumped the realtek and are production ready with a PHY from microchip .....
https://olimex.wordpress.com/2016/09/19/...roduction/

(09-26-2016, 02:58 PM)waldo Wrote: [ -> ]Back to the topic at hand ..... any updates on the GbE issue ?

Tllim, anyone ; could you update us on progress anywhere ?
1 Patch from olimex to do some magic with the autoneg
2 Possible Powerpath issue
3 Possible takeback of impacted boards

Meanwhile olimex seems to have dumped the realtek and are production ready with a PHY from microchip .....
https://olimex.wordpress.com/2016/09/19/...roduction/

1. No aware there is autoneg patch from Olimex, please provide link.

2. We have collect several boards that having gigabit ethernet and already in hardware engineer hands.

(09-27-2016, 07:56 PM)tllim Wrote: [ -> ]

(09-26-2016, 02:58 PM)waldo Wrote: [ -> ]Back to the topic at hand ..... any updates on the GbE issue ?

Tllim, anyone ; could you update us on progress anywhere ?
1 Patch from olimex to do some magic with the autoneg
2 Possible Powerpath issue
3 Possible takeback of impacted boards

Meanwhile olimex seems to have dumped the realtek and are production ready with a PHY from microchip .....
https://olimex.wordpress.com/2016/09/19/...roduction/

1. No aware there is autoneg patch from Olimex, please provide link.

2. We have collect several boards that having gigabit ethernet and already in hardware engineer hands.

 If you'd please be so kind as to keep us updated on any progress anywhere concerning this , that'd be great, I (and I imagine a lot of peeps with me) am holding off buying more pine's until this is fixed ....
Even if progress is small just update us every two weeks for example ... I think that 'll keep a lot of us from asking the same questions over and over again


heres the patch I was talking about (and have been mentioning for months btw) ....olimex needed it first to fix their a20 boards iirc
http://lists.denx.de/pipermail/u-boot/20...49734.html
==> it 'fakes' auto-negotiations so they become master for sure , which made the a20 board behave stable :S
 net: phy: Optionally force master mode for RTL PHY
 sunxi: A20-Olimex-SOM-EVB: Force 8211CL to master
 sunxi: A20-OLinuXino-Lime2: Force 8211CL to master


I know this mentions the CL variant as opposed to our 8211E, but i seem to remember their issues were the quite same .... been a while since I found the patch ... so i don't remember the details
even more info : https://www.mail-archive.com/u-boot@list...07006.html

(09-28-2016, 01:59 PM)waldo Wrote: [ -> ]heres the patch I was talking about (and have been mentioning for months btw) ....olimex needed it first to fix their a20 boards iirc
http://lists.denx.de/pipermail/u-boot/20...49734.html
==> it 'fakes' auto-negotiations so they become master for sure , which made the a20 board behave stable :S
 net: phy: Optionally force master mode for RTL PHY
 sunxi: A20-Olimex-SOM-EVB: Force 8211CL to master
 sunxi: A20-OLinuXino-Lime2: Force 8211CL to master


I know this mentions the CL variant as opposed to our 8211E, but i seem to remember their issues were the quite same .... been a while since I found the patch ... so i don't remember the details - even more info : https://www.mail-archive.com/u-boot@list...07006.html

But then I believe you can't have two "broken" boards on the same network. But if you only have one PINE, and if the patch works, you'd be fine.

(09-29-2016, 03:17 PM)amc2012 Wrote: [ -> ]

(09-28-2016, 01:59 PM)waldo Wrote: [ -> ]heres the patch I was talking about (and have been mentioning for months btw) ....olimex needed it first to fix their a20 boards iirc
http://lists.denx.de/pipermail/u-boot/20...49734.html
==> it 'fakes' auto-negotiations so they become master for sure , which made the a20 board behave stable :S
 net: phy: Optionally force master mode for RTL PHY
 sunxi: A20-Olimex-SOM-EVB: Force 8211CL to master
 sunxi: A20-OLinuXino-Lime2: Force 8211CL to master


I know this mentions the CL variant as opposed to our 8211E, but i seem to remember their issues were the quite same .... been a while since I found the patch ... so i don't remember the details - even more info : https://www.mail-archive.com/u-boot@list...07006.html

But then I believe you can't have two "broken" boards on the same network. But if you only have one PINE, and if the patch works, you'd be fine.

The auto negotiation is on a per port basis if i remember correctly,...
I do think that it would remain only a 'patch' not a real solution, ... 
I could live with it until a permanent solution is found ....which for olimex seems to have meant ... drop realtek
Edit: F**k it ; i would be happy just to get GbE working; even with some ugly patch

Doesn't look like slave/master role is of any impact on RTL8211E PHY. I can force slave or master mode on the NIC of the connected PC and PINE64 PHY reports corresponding opposite role, but packet loss persists when pinging from PINE64 to the connected device. Forcing role on PINE64 PHY also results in correct role on both sides, also of no effect on the problem.

1. PINE64 - Auto mode (PHY reg 0x9 = 0x0300), PC - Auto mode
PINE64 PHY reg 0xA = 0x3800 = Gigabit Slave
11 packets transmitted, 8 received, 27% packet loss, time 9999ms

2. PINE64 - Auto mode (PHY reg 0x9 = 0x0300), PC - Slave mode
PINE64 PHY reg 0xA = 0x7800 = Gigabit Master
14 packets transmitted, 9 received, 35% packet loss, time 13005ms

3. PINE64 - Master mode (PHY reg 0x9 - 0x1A00), PC - Slave mode
PINE64 PHY reg 0xA = 0x7800 = Gigabit Master
14 packets transmitted, 10 received, 28% packet loss, time 13008ms

4. PINE64 - Slave mode (PHY reg 0x9 - 0x1200), PC - Slave mode
PINE64 PHY reg 0xA = 0x0000 = Master/Slave fault, not capable of 1Gbps, up at 100Mbps
46 packets transmitted, 46 received, 0% packet loss, time 45001ms

5. PINE64 - Slave mode (PHY reg 0x9 - 0x1200), PC - Master mode
PINE64 PHY reg 0xA = 0x3800 = Gigabit Slave
13 packets transmitted, 11 received, 15% packet loss, time 12004ms

6. PINE64 - Slave mode (PHY reg 0x9 - 0x1200), PC - Auto
PINE64 PHY reg 0xA = 0x3800 = Gigabit Slave

19 packets transmitted, 6 received, 68% packet loss, time 18004ms

(09-29-2016, 07:39 PM)stepw Wrote: [ -> ]Doesn't look like slave/master role is of any impact on RTL8211E PHY. I can force slave or master mode on the NIC of the connected PC and PINE64 PHY reports corresponding opposite role, but packet loss persists when pinging from PINE64 to the connected device. Forcing role on PINE64 PHY also results in correct role on both sides, also of no effect on the problem.

Good that we can check another thing off the list. Thanks for the report!