(In reply to hlh from comment #0)

I'm one of the ones from the exchange that you reference
for the BPI-M3 (see the prior and next messages by
thread from the one that you referenced). You referenced:

https://lists.freebsd.org/pipermail/freebsd-arm/2016-December/015137.html

I eventually solved my problem on the BPI-M3. That was now
months ago: I've not had such a problem in months.

Out of all the things that I tried what made the difference
was replacing the power supply that I was using to power the
BPI-M3. After that the BPI-M3 worked and had no more Ethernet
problems, both in the unusual environment that I was in back
then and in my usual environment when I returned. It still
works just fine.

This change was made and tested for a time without making
any other simultaneous changes. I eventually started updating
the BPI-M3 FreeBSD and ports again.

Note: I did not expect the power supply change to make the
difference based on the symptoms and other uses of the
power supply that I'd made. But I tried replacing it 
with a different model power supply anyway. (The
problem might be the individual power supply rather
than a model but I tried a different model.)

I've not done anything to examine the properties of the
output of the bad/odd power supply when powering the
BPI-M3 (or any other use). So I do not know what its
technical issue(s) are that a BPI-M3 might be sensitive
to.

I just try with another power supply (different model too) to no avail.

Henri

(In reply to hlh from comment #2)

I can not claim power-supplies/power-connection
are always the issue. I just note that they can
be. It might be that different ways of managing
the hardware in the software are somewhat more
or less sensitive to power supply issues when the
power supply does matter. So different operating
systems (or versions of the same operating
system) might get different results in marginal
power contexts.

I also have access to a Pine 64+ 2GB and use it.

For it I use an official RPI-3 power supply.
It worked better than the others that I tried.
It was obvious up front in my case that there
were power problems for the initial power
supply that I used for the Pine64+. (The RPI-3
power supply is 5.1V based as I remember,
designed to be somewhat less likely to have a
important, temporary voltage drop for a
micro-usb style of connection.)

On the BPI-M3 that I was using was a barrel
plug instead of a micro-usb connector. (They
have produced it both ways.) I doubt that
the micro-usb connector style would have been
reliable with any power supply using that
connector given what I observed with the better
barrel plug type of connection and various
devices using micro-usb connectors.

I just think that if debian work, FreeBSD can/must work with such a power supply.

By the way it work for me during 3 weeks. Does a power supply can be altered by a power fail?

(In reply to hlh from comment #4)

Power supplies do have failure modes.

For example for the one that I eventually
replaced for the BPI-M3: The BPI-M3 had
an uptime of something like 22 days where
it had been in use over Ethernet with that
power supply connected. The power supply
used to work well and was fairly new.

This was somewhat before I started having
problems. The 22 days only ended because
I decided to shut the BPI-M3 down
temporarily. It still worked when powered
back on. It was a few days later that I
started having problems as I remember.

But this sequence did not involve a power
loss to an area I was in. Odd power can
damage electronics. But as I understand
that is usually more tied to odd initial
power when power starts to be restored
to an area. I'm not sure how likely a
power supply is to be damaged by such.

I can not claim what your problem actually
is. I only report that, for the old BPI-M3
symptoms that you referenced, an odd power
supply can lead to similar symptoms for
a BPI-M3.

I have never seen such symptoms on the Pine
64+ 2GB. But the Pine 64+ 2G is running a
somewhat older vintage of FreeBSD than you
are running: I'd been focusing on aarch64
problems and now on 32-bit powerpc problems
recently and have not been updating some of
the various machines that I have access to.

I try  to boot with:

FreeBSD-aarch64-12.0-GENERIC-317973M.img.gz

from RaspBSD and now awg is detected and working.

Comment 7 Ed Maste 2017-05-27 01:38:24 UTC

> now awg is detected and working

In other words this problem is now solved?

I'm not sure.

I encounter another problem with CURRENT-r317181
(see https://lists.freebsd.org/pipermail/freebsd-current/2017-May/065875.html)
and to solve it I create a kernel config with only the devices detected at boot.
All seems working (root on zfs and awg0).

Then after a power failure awg show 'soft reset timed out'.

I try the image r317973 from RaspBSD with a GENERIC config and awg work.
I try with my slimmed kernel config and awg show the timeout again.

I added step by step the following devices:

104a105
> device		al_eth		# Annapurna Alpine Ethernet NIC
130a132
> device		dwcotg			# DWC OTG controller
143a146,147
> device		aw_rsb			# Allwinner Reduced Serial Bus
> device		bcm2835_bsc		# Broadcom BCM283x I2C bus
167a172,175
> # SPI
> device		spibus
> device		bcm2835_spi		# Broadcom BCM283x SPI bus
> 

and now awg is working. Strange!!!

But if I load zfs and opensolaris the kernel do not start:

>> FreeBSD EFI boot block
   Loader path: /boot/loader.efi

   Initializing modules: ZFS UFS
   Probing 3 block devices.....* done
    ZFS found no pools
    UFS found 1 partition
Consoles: EFI console  
Command line arguments: loader.efi
Image base: 0xb8dc5000
EFI version: 2.05
EFI Firmware: Das U-boot (rev 0.00)

FreeBSD/arm64 EFI loader, Revision 1.1
(Sat May 27 12:46:34 CEST 2017 hlh@chamonix.restart.bel)
EFI boot environment
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=0x71b148 data=0x9def8+0x39d87e syms=[0x8+0xf4b78+0x8+0xe95c1]
/boot/entropy size=0x1000

Hit [Enter] to boot immediately, or any other key for command prompt.


Type '?' for a list of commands, 'help' for more detailed help.
OK load zfs
/boot/kernel/zfs.ko text=0x9e3a0 text=0xe11f0 data=0x214d0+0x9eb78 syms=[0x8+0x1d760+0x8+0x1884c]
OK load opensolaris
/boot/kernel/opensolaris.ko text=0x1a00 text=0xda0 data=0x10178+0x125b8 syms=[0x8+0x1020+0x8+0x8ca]
OK boot
Booting...
Using DTB provided by EFI at 0x49000000.
... freeze here ...

At first I think that the DTB was smashed and I add to my kernel config:

options         FDT_DTB_STATIC          # Statically embed a DTB file into a kernel image
makeoptions     FDT_DTS_FILE=pine64_plus.dts

but this do not solve the boot problem with zfs.

Moreover if I don't add the previous devices another problem show up:

cpufreq_dt0: <Generic cpufreq driver> on cpu0
cpufreq_dt0: no regulator for cpu@0
device_attach: cpufreq_dt0 attach returned 6

and sysctl dev.cpu.0 do not show the freq_levels and freq

Thanks for your time

Henri

Comment 9 Emmanuel Vadot 2018-08-20 18:22:12 UTC

Is this problem still happening ?

(In reply to Emmanuel Vadot from comment #9)

Yes the problem is solved.

Just one strange thing, at the loader, when I load zfs, opensolaris is not automatically loaded as in other architecture. So I have in loader.conf.local:

...
zfs_load="YES"                          # Load ZFS module
opensolaris_load="YES"                  # Opensolaris not loaded automatically